fork-ts-checker-webpack-plugin: ESLint checking from the 1st compilation blocks 2nd webpack compilation (tapAfterCompileToAddDependencies)
Current behavior
- During the initial compilation, fork-ts-checker starts doing its thing, and one of these things is
getDependencies. - Dependencies resolution will be written to
dependenciesPromise - Next webpack compilation will stumble upon
tapAfterCompileToAddDependencieshook. - If dependencies weren’t resolved yet, this compilation will be blocked until fork-ts-checker finishes its job.
- My first initial compilation takes ~22 seconds.
- Initial TS+ESLint checks take something like 2 minutes.
- Without this plugin an HMR recompilation takes 1-2 seconds.
- Issue: With the plugin, an HMR recompilation will have to wait for
dependenciesPromiseto resolve which means I can’t use the app for the next 2 minutes while plugin is doing all the checks.
Illustration of the issue at hand, hope it’s not too messy (I added a couple of logs to show how much time tapAfterCompileToAddDependencies takes).

Note: I can disable ESLint and this doesn’t happen. getDependencies takes so long for ESLint specifically.
Expected behavior
Not sure how this should be fixed, but maybe this can work?
- Don’t tap into afterCompile hook.
- Wait until
getDependenciesresolves and only after that tap some hook and add resolved dependencies into next webpack compilation?
I couldn’t really make this work locally for me, but if you can point me to the right solution, I can make a PR.
Steps to reproduce the issue
- Have a project big enough for ESLint’s getDependencies to take considerable time.
- Compile with webpack and immediately do an HMR recompilation - easiest use-case is when
lazyCompilationis enabled. - Notice how 2nd webpack compilation will only finish when fork-ts-checker is finished.
Issue reproduction repository
I can try to create one if description above isn’t enough.
Environment
- fork-ts-checker-webpack-plugin: 6.2.6
- typescript: 4.1.2 (irrelevant I think)
- eslint: 7.8.1
- webpack: 5.35.0
- os: win10
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 6
- Comments: 26
Commits related to this issue
- feat: use separate workers for dependencies and issues In order to not block next iteration on getDependencies call, we use separate worker for dependencies calculations (so getIssues from previous c... — committed to TypeStrong/fork-ts-checker-webpack-plugin by piotr-oles 3 years ago
- feat: use separate workers for dependencies and issues (#636) In order to not block the next iteration on the getDependencies call, we use a separate worker for dependencies calculations (so getIssue... — committed to TypeStrong/fork-ts-checker-webpack-plugin by piotr-oles 3 years ago
🎉 This issue has been resolved in version 6.3.0 🎉
The release is available on:
Your semantic-release bot 📦🚀
@rkriauciukas-freesat I think it’s not related to this issue - @caiquelsousa could you open a new issue regarding
WatchMissingNodeModulesPlugin?