Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
fix: support long running "watch" lint sessions #973
This PR adds support for watching directories and configuration files so that we can force typescript to recalculate the program if new files are added.
In this PR I also setup typescript project references for the repo.
There is one very, very minor problem with this that I don't know how to solve right now.
This means that if the editor is particularly quick to open the file (<250ms), then the initial lint of the empty file will throw the "file not in project" parsing error.
However I figured out this doesn't last long. If you start typing, then the plugin will re-lint the file (which now exists in the ts program), and the parser error will disappear. Or you can close and reopen the file.
Video showing it off working in VSCode: https://youtu.be/0My26ejZJVk
Thanks for the PR, @bradzacher!
typescript-eslint is a 100% community driven project, and we are incredibly grateful that you are contributing to that community.
The core maintainers work on this in their personal time, so please understand that it may not be possible for them to review your work immediately.
I tried to do something tricky, but it didn't seem to work:
When you call the watchDirectory callback, typescript schedules an the update for 250ms later (so it doesn't trigger multiple updates for a "save all files" cycle from an IDE).
Because the parser isn't asynchronous, we can't wait for this time... grr
I did some research into handles in NodeJS.
I don't see a way to create "weak" handles (i.e. handles which won't block the process).
So I guess that either we get eslint to better support stateful parsers, or we create our own CLI wrapper.
Another option is to have a virtual program host (fork-ts-checker-webpack-plugin pull request) or a language service host (ts-node) that would use actual file content provided by eslint (which also can give better support for virtual TypeScript files, like in Vue) and when file is linted again just update it. Though it still may require some changes in eslint since it would need to have all files for the first lint, but maybe there are workarounds.
I'll investigate this more tonight!
We do do that already. We treat eslint as the source of truth for file contents - to the point that we don't even attach file system watchers for any of the js/ts files being linted!
The problem is that when in watch mode, new files can be introduced. These files are do not exist in the ts program that's already been constructed.
So we need a way to tell when we need to tell typescript to update the program. This is where watching the directories (and watching the tsconfigs) comes in:
I did think about an approach that involves us manually checking an unknown file against the provided tsconfigs to determine which programs to recalculate, but there are two problems with this:
@@ Coverage Diff @@ ## master #973 +/- ## ========================================== - Coverage 94.18% 94.01% -0.17% ========================================== Files 115 115 Lines 5022 5064 +42 Branches 1406 1416 +10 ========================================== + Hits 4730 4761 +31 - Misses 165 175 +10 - Partials 127 128 +1