Enable caching for ESLint #8296
Conversation
nodejs-github-bot
added
build
|
How does the cache work? Especially, how does it detect changes to files? Does it just compare mtime? |
|
mtime and size of the file It also stores the hash of the config file for the last time that particular file was linted. That means there is a pitfall if you change your .eslintrc file, you've invalidated your entire cache and it will have to be recreated on the next run. But I suspect that those of us who tweak the .eslintrc file with any frequency are a tiny minority of contributors... |
|
If you want more info on how it determines if a file has changed:
|
|
The main challenge with using caching in the parallelized script is that each worker would need its own cache file ( |
|
I'd squash the last two commits together, but LGTM. Speeding up the linter is 😍 |
|
Will the cache be invalidated when a new ESLint version is used? |
|
Rubber stamp LGTM. |
Yes. |
|
Looks fine in windows, LGTM |
|
(CI is green) |
|
LGTM, maybe you can squash the second and third commit as mentioned. |
PR-URL: nodejs#8296 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: Roman Reiss <[email protected]>
PR-URL: nodejs#8296 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: Roman Reiss <[email protected]>
PR-URL: nodejs#8296 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: Roman Reiss <[email protected]>
PR-URL: nodejs#8296 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: Roman Reiss <[email protected]>
PR-URL: #8296 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: Roman Reiss <[email protected]>
PR-URL: #8296 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: Roman Reiss <[email protected]>
|
@Trott do you want to backport these linter changes? |
PR-URL: nodejs#8296 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: Roman Reiss <[email protected]>
PR-URL: nodejs#8296 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: Roman Reiss <[email protected]>
|
@thealphanerd It looks like we've skipped a number of ESLint updates on v4.x at this point. My inclination would be to not start now, if there's a lot of annoyance involved and not much benefit. Fine by you if we mark this as dont-land and revisit if it becomes necessary? (We can always do a separate update to whatever ESLint version just for v4.x if we want to.) |
Checklist
make -j4 test(UNIX), orvcbuild test nosign(Windows) passesAffected core subsystem(s)
tools
Description of change
This PR is in 3 separate commits:
.eslintcachefile to.gitignoreMakefileandvcbuild.bat(Oh, hey, can someone on Windows grab this branch and test thevcbuild.batchange to thejslinttask?)Here's my crude benchmarks:
make jslintthe first time (no cache) with this change: 11 seconds or somake jslinton current master: 8 seconds or somake jslintsubsequent times (populated cache) with this change: 1 secondHere's my thinking:
make jslintis something that gets done again and again in a dev environment. It's worth an extra 3 seconds or so on the first run if it shaves 7 seconds or so on subsequent runs.However, in CI, it just gets run once. So the current parallelizing script is the faster option on CI.
It is possible to enable caching in the parallelizing script, but I'm not sure it's worth the complexity. That can be a subsequent enhancement if it is highly desirable. It's possible (I think) that it will not be measurably better than one job with one cache. Would have to be measured, of course.
/cc @mscdex