You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When async is set to true, issues will be surfaced asynchronously via tapDoneToAsyncGetIssues. However, the first recompilation gets blocked in tapAfterCompileToAddDependencies due to the webpack compilation waiting on state.dependencies promise. When TS compilation is very slow or broken (as there seemed to be in 4.3.2 for us), this causes webpack compilation to hang with no indication of what is going wrong.
Expected behavior
When async is set, triggering a recompilation via file save should happen immediately, instead of being stuck behind initial TS project compilation to add dependencies.
Steps to reproduce the issue
It is tough to create a clear repro because this only happens when repo is so big or having issues that this step takes a long time. To emulate it, you can set state.dependenciesPromise to just be a very long sleep promise and see that recompilations after the first can not start until that is complete.
Proposed fix
I have attached a proposed fix patch that is working for us. I worry I may be missing some potential leak by not waiting for this promise, but it has been working will in our large repo for about a week now
diff --git a/node_modules/fork-ts-checker-webpack-plugin/lib/hooks/tapAfterCompileToAddDependencies.js b/node_modules/fork-ts-checker-webpack-plugin/lib/hooks/tapAfterCompileToAddDependencies.js
index f5155a2..589846a 100644
--- a/node_modules/fork-ts-checker-webpack-plugin/lib/hooks/tapAfterCompileToAddDependencies.js
+++ b/node_modules/fork-ts-checker-webpack-plugin/lib/hooks/tapAfterCompileToAddDependencies.js
@@ -10,7 +10,11 @@ var __awaiter = (this && this.__awaiter) || function (thisArg, _arguments, P, ge
};
Object.defineProperty(exports, "__esModule", { value: true });
function tapAfterCompileToAddDependencies(compiler, configuration, state) {
- compiler.hooks.afterCompile.tapPromise('ForkTsCheckerWebpackPlugin', (compilation) => __awaiter(this, void 0, void 0, function* () {
+ const tapFn = configuration.async
+ ? compiler.hooks.afterCompile.tap
+ : compiler.hooks.afterCompile.tapPromise;
+
+ tapFn.call(compiler.hooks.afterCompile, 'ForkTsCheckerWebpackPlugin', (compilation) => __awaiter(this, void 0, void 0, function* () {
if (compilation.compiler !== compiler) {
// run only for the compiler that the plugin was registered for
return;
Environment
fork-ts-checker-webpack-plugin: 6.2.13
typescript: 4.3.2
eslint: NA
webpack: 5.46.0
os: Windows
The text was updated successfully, but these errors were encountered:
I can't add it to async, because it will create some race conditions in how webpack watches files. This will also potentially break our E2E tests :/
I'm working on a new release of the plugin which will have a separate thread for dependencies and separate for diagnostics. It will still be sync for dependencies, but computing dependencies on its own should be fast enough (it only parses tsconfig.json file(s)). Currently it can be blocked by diagnostics checks because it runs on the same thread and typescript diagnostics are synchronous.
In order to not block the next iteration on the getDependencies call, we use a separate worker for dependencies calculations (so getIssues from the previous compilation will not block the next getDependencies call)
✅ Closes: #612, #634
Current behavior
When
async
is set totrue
, issues will be surfaced asynchronously viatapDoneToAsyncGetIssues
. However, the first recompilation gets blocked intapAfterCompileToAddDependencies
due to the webpack compilation waiting onstate.dependencies
promise. When TS compilation is very slow or broken (as there seemed to be in 4.3.2 for us), this causes webpack compilation to hang with no indication of what is going wrong.Expected behavior
When
async
is set, triggering a recompilation via file save should happen immediately, instead of being stuck behind initial TS project compilation to add dependencies.Steps to reproduce the issue
It is tough to create a clear repro because this only happens when repo is so big or having issues that this step takes a long time. To emulate it, you can set
state.dependenciesPromise
to just be a very long sleep promise and see that recompilations after the first can not start until that is complete.Proposed fix
I have attached a proposed fix patch that is working for us. I worry I may be missing some potential leak by not waiting for this promise, but it has been working will in our large repo for about a week now
Environment
The text was updated successfully, but these errors were encountered: