New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New: do not remove non visited files from cache. (Fixes #6780) #6921
Conversation
Thanks for the pull request, @royriojas! I took a look to make sure it's ready for merging and found some changes are needed:
Can you please update the pull request to address these? (More information can be found in our pull request guide.) |
Thank you for your pull request. It looks like this may be your first contribution to a jQuery Foundation project, if so we need you to sign our Contributor License Agreement (CLA). 📝 Please visit http://contribute.jquery.org/CLA/ to sign. After you signed, the PR is checked again automatically after a minute. If there's still an issue, please reply here to let us know. If you've already signed our CLA, it's possible your git author information doesn't match your CLA signature (both your name and email have to match), for more information, check the status of your CLA check. |
LGTM |
Thanks @royriojas! I'm going to take a look at this and try it out tomorrow. We're also still waiting for a reply from the rest of the team on the issue, to determine whether this should wait for a major version bump or not. |
Sure man! hope this solves the issue |
Adding "do not merge" for now as the issue is still not accepted! |
I did some unscientific timings while linting the node.js repo (the largest project I could think of that uses ESLint). As far as I can tell, there are 3,818 JavaScript files in that repo. Linting them without a cache takes When using Next, I deleted about half the files in the repo, and ran the lint again (still using Incidentally, the PR seems to do what it is intended to do. Deleted files are removed from the cache, but running eslint against a subset of cached files does not clear out the other cached files (the original point of #6780). All-in-all, I really hope we can move forward with this, because I think the performance hit from checking for removed files is minuscule even in this contrived case, and the gains from consistent caching are huge. Thanks for the great work, @royriojas. Think of all the hours of human lives you've saved already! |
I've accepted the issue, so I believe this is ready for review/merge. |
My only concern with this PR is that the newly added tests have multiple action/assertion sections (in other words, these are not unit tests, they're functional tests). If that's acceptable to everyone else, I'm okay with it. |
I agree, and was going to make that same point. @royriojas, do you think you could break up the tests a bit to only test one thing at a time? |
@IanVS, @platinumazure I just copied the tests that were there before and modified them a bit :), so I was thinking it was ok to have that many assertions. I can break the tests, will do that tonight. |
LGTM |
@IanVS, @platinumazure I removed some of the assertions and only left the assertion to check what the test was actually expecting. Please let me know if that is good enough |
LGTM |
I'm not seeing the tests having been broken down-- am I missing something? |
He squashed the changes. There used to be more unrelated assertions. There are indeed still a few assertions, but I think they're reasonable given the test. For example in the first test, he checks that the file is in the cache after the first lint run in order to establish that the removal is happening properly in the next linting run. Caching is inherently a two-part process, and in my mind at least these tests are reasonable. Happy to hear opinions from others though. |
Fine by me. Usually in cases like this, I like to see two tests: One that checks the file is still present after 1 run, and one test that does 2 runs and checks the file is gone after the second run. But I admit it might be overkill for this case. So the changes LGTM. |
Yes, but then isn't there the danger that one of the tests and code is changed at some point, and then they no longer are connected? I guess the only real way to assure that doesn't happen is to make a helper function that they both share, but it seems like overkill to me. |
* helper method to delete the cache files created during testing | ||
* @returns {void} | ||
*/ | ||
function delCache() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe a nitpick, but could we call this deleteCache
instead? There's no need to abbreviate delete
to del
here.
* helper method to delete the cache files created during testing | ||
* helper method to delete a file without caring about exceptions | ||
* | ||
* @param {string} filePath The file path |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we get rid of the extra whitespaces between @param
and {string}
here?
LGTM |
@vitorbal Code was updated! |
LGTM, waiting for @vitorbal to approve. |
Lgtm!
|
Thanks for your contribution, @royriojas! 🎉 |
What issue does this pull request address?
It allows cache file to keep non used files in the cache between executions of eslint, also files that don't exist anymore are removed from the cache both when loaded and when saved.
What changes did you make? (Give an overview)
Is there anything you'd like reviewers to focus on?
cc. @IanVS