Skip to content
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

async setting is not respected for tapAfterCompileToAddDependencies #634

Closed
markjm opened this issue Jul 27, 2021 · 3 comments
Closed

async setting is not respected for tapAfterCompileToAddDependencies #634

markjm opened this issue Jul 27, 2021 · 3 comments

Comments

@markjm
Copy link
Contributor

markjm commented Jul 27, 2021

Current behavior

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
@markjm markjm added the bug label Jul 27, 2021
@piotr-oles
Copy link
Collaborator

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.

piotr-oles added a commit that referenced this issue Aug 1, 2021
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
@piotr-oles
Copy link
Collaborator

There should be a new version released in a few minutes. It should fix this issue :) Could you confirm?

@markjm
Copy link
Contributor Author

markjm commented Aug 4, 2021

Let me try it later this week. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants