Skip to content

Commit 88af1e7

Browse files
committed
Per code review comment, answering Help Needed item and moving it to Open Questions.
1 parent c4597a7 commit 88af1e7

File tree

1 file changed

+4
-15
lines changed

1 file changed

+4
-15
lines changed

designs/2023-relative-cache/README.md

Lines changed: 4 additions & 15 deletions
Original file line numberDiff line numberDiff line change
@@ -186,24 +186,13 @@ replacement would be fragile at best.
186186
187187
## Open Questions
188188
189-
No.
189+
Question: Should we make every cache shareable, or keep the shreable-cache flag default to false?
190190
191-
## Help Needed
192-
193-
Decision needed: Make every cache shareable, or keep the shreable-cache flag default to false?
191+
Answer: We don't know how people are currently using the cache file, so we can't make assumptions about what is and isn't safe to change. Even if we made a shareable cache the default (which would be a breaking change), we'd still need a way to enable the previous behavior in case there is a use case we aren't aware of..
194192
195-
I originally planned the shareable-cache flag so that users of eslint could not be surprised by changed cache behavior, and would also not have to regenerate their cache
196-
for a patch version change. But I discovered by testing that there is no way to NOT force people to regenerate their eslint cache with this change. That's because by adding
197-
the 'shareable-cache' flag, it adds a property to the ConfigArray object. Even if it's set to false (the old behavior), the object's structure changes with a new property
198-
field. This in turn changes the ConfigArray object's stringify results, which are fed into a hash function to create a hash key. (See lint-result-cache.js function hashOfConfigFor.)
199-
In turn, that becomes a part of the eslintcache file. I think it's so that everything will be re-scanned with configuration changes.
200-
201-
For that reason, should we simply have a shareable cache full of relative paths be the only behavior? That means no command line flag, and strictly internal changes that
202-
would be invisible to the end user. On the other hand, if this change DOES have undesirable side effects because people are using eslint in unexpected ways, having the flag
203-
default to the old behavior would save them from surprises on upgrade. Judging by the number of .gitignore files with .eslintcache in them, people are used to this
204-
cache not being shareable.
193+
## Help Needed
205194
206-
What would the eslint team prefer? No flag, or keep the shareable-cache flag and default to false?
195+
None at this time.
207196
208197
## Frequently Asked Questions
209198

0 commit comments

Comments
 (0)