Stale version of interface from another file being used on second linter run with caching disabled #4733
Comments
We actually do do caching! We have to because for any non-trivial sized project it will take way too long to recalculate the state for the entire project. However, for various reasons we cannot attach file watchers. ESLint isn't designed for this sort of persistent system. This is how an IDE works - all changes you make will be linted. This is all also why we cannot work with ESLint's inbuilt caching mechanism. In your given example the order matters because in one order we are informed of the changes in dependency order, and thus we can lint correctly. In the other order we cannot. Sadly this isn't much we can do here. If the tool doesn't inform us of the changes in an order based on the file dependencies, then we can't work correctly. |
|
Thank you so much for the quick response! So if I'm understanding you right, what I'm seeing here is the expected behavior and it's ESLintWebpackPlugin's responsibility to pass files into eslint.lintFiles in the proper order so I should file an issue against them? |
|
I wouldn't say that it's specifically their fault - they don't know how TS-eslint works or its In a nutshell linting over "changed files only" is exactly the same as doing an eslint cached lint run (it caches state to disk so the next run only lints changed files). We do not and cannot support this style of linting. Perhaps the webpack plugin can add some logic to satisfy most usecases? But it's probably going to be super difficult As an example - if there are cycles in your dependency graph then it's not possible to satisfy the constraint of "in dependency order", which would cause buggy behaviour. Most projects avoid runtime cycles, but type cycles are very, very common - which would cause problems. I don't know if this is a solvable problem, unfortunately. We here have to focus on the main two usecases - CLI runs ("one and done" linting) and IDE runs ("continuous" linting). I'd be open to having someone work on a specification to help aid this usecase! But it won't be a small amount of work, to say the least. |
Uh oh!
There was an error while loading. Please reload this page.
Repro
If you run
node index.json this stackblitz and follow the instructions it prints, you'll run into the error: https://stackblitz.com/edit/node-skp6gk?file=index.jsGenerally, I run into this when I have one file containing an interface with a property and another file that references that property. Then following these steps gets me a "@typescript-eslint/no-unnecessary-type-assertion" error on step 3:
If I then kill the node process that I'm running the linter from and restart it, it doesn't throw the error on step 1. Additionally, if I swap the order that the files go into the linter that seems to fix it too.
Expected Result
I expect that without any caching enabled, there shouldn't be a case where running eslint.lintFiles on a file a second time would give me an error based on the state of the files when they were passed into eslint.lintFiles the first time.
Actual Result
Even after disabling any kind of ESLint caching, following the steps in the repro case causes a linter error even though the passed in files are correctly formatted.
Additional Info
Sorry if this is on the wrong repo, I don't understand enough about the inner workings to be sure this is the right place.
I ran into this using ESLintWebpackPlugin, which uses webpack's compilation hooks to determine what files have changed during a rebuild and passes an array of their absolute paths into eslint.lintFiles. Before opening a bug with them to see if there's a way to order this list to put dependencies before files they depend on, I want to make sure that the lintFiles function having a required order for files that are passed into it is deliberate.
Versions
@typescript-eslint/parser5.16.0TypeScript4.6.3ESLint8.11.0node14.19.0The text was updated successfully, but these errors were encountered: