Fork-ts-checker-webpack-plugin: v2.0.0 breaks async: false

Created on 28 Oct 2019  路  17Comments  路  Source: TypeStrong/fork-ts-checker-webpack-plugin

Current behavior

If I have async: false, our webpack build (webpack-dev-serverwill not finish and just stuck atwait until bundle finished`

Expected behavior

In v1.6.0, this does not happen.

Steps to reproduce the issue

I am using this plugin with eslint, typescript-eslint, webpack and ts-pnp (similar to the setup of create-react-app).
I have async: false in webpack config and that's when I see problem with 2.0.0. async:false is kind of important to me because I want to fail the webpack build when there are type issues (warning or error), also I want webpack to be the reporter of error because I have a decent error format reporter there :). As such I want to block webpack build to finish until this plugin's done with checking type, but somehow after upgrading to 2.0.0 that nolonger happens.

Issue reproduction repository

Really sorry the project I'm working on doesn't have a public repo so it would take me time to create a repo for this

Environment

  • fork-ts-checker-webpack-plugin: 2.0.0
  • typescript: 3.6.4
  • webpack: 4.41.2
  • os: Windows 10

P/S: Honestly though the more I think about this the more I want to ask you guys what's your view on this? Do you want to fail a build when there are typescript/linting errors?
I don't know of a way to have async:true and still fail webpack compilation build using this plugin` :(, let me know if I miss some config. Thanks!

bug released

Most helpful comment

:tada: This issue has been resolved in version 3.0.1 :tada:

The release is available on:

Your semantic-release bot :package::rocket:

All 17 comments

This is related to @fatme PR here: https://github.com/TypeStrong/fork-ts-checker-webpack-plugin/pull/337

cc @piotr-oles

If I have async: false, our webpack build (webpack-dev-serverwill not finish and just stuck atwait until bundle finished`

I'm guessing you're running in watch mode rather than doing a production build?

Do you want to fail a build when there are typescript/linting errors?

Most definitely. But speaking for myself (and create-react-app does the same) I only run with async: false for the production build.

I'm not totally clear what the issue is here; we won't be able to do much without a repro repo I'm afraid.

Hello,

I can confirm that this is indeed an issue. I will try to create a repro.

@johnnyreilly Sorry it will take me time to build a repro repo. In the meantime I did a little bit of digging. I just needed to change this line back to use emit hook.

Also another thing, when I'm building production (i.e. not in watch mode and async=false), I notice emit is called multiple times if afterCompile hook is used but only called one when emit hook is used.

Hello,

I did some testing and was able to create a repro. You can find it here

https://github.com/swashata/fork-ts-checker-issue

The thing is

  1. If there is a style.scss or style.less import, then the plugin fails in async:false mode.
  2. If there are more than one style.scss or style.less import, then the plugin hangs in async:false mode.

Kindly read the README of the repository for more information. If I comment out both the style file imports, then the plugin works just fine.

Also

Also another thing, when I'm building production (i.e. not in watch mode and async=false), I notice emit is called multiple times if afterCompile hook is used but only called one when emit hook is used.

You are correct about this. I was working on my tooling wpackio and I notice this behavior. The afterCompile I believe is called for every files compiled? (entrypoint, chunk files etc).

Thanks all - let's use this issue as a place to discuss this. @fatme can you be part of this if possible?

We want to land on a solution that suits all parties; it sounds at present that 2.0.0 works well for @fatme use cases but not for @blacksteed232 and @swashata.

It's possible we may want to revert the changes of 2.0.0. But let's see if we can work towards a future which serves all cases.

I'm wondering if the (now default) behaviour introduced in 2.0.0 should actually be opt in as described here: https://github.com/TypeStrong/fork-ts-checker-webpack-plugin/pull/337#issuecomment-545594920 (Though I'm not generally keen on a multitude of behaviours in the same plugin. Let's see.)

Yeah,

But I am most interested in the part that why in async:false mode, the plugin fiddles with what comes from style files. And if there is more than one style file it completely hangs.

I must say I am relieved though. Have been banging my head over wall to figure out why the build was failing. At first I thought, it was something to do with mini-css-extract-plugin, but it turns out to be this.

One thing I would like to add more is that, if I use style-loader instead of MiniCssExtractPlugin.loader, the issue just goes away.

Thanks for the repro repo @swashata - that's super helpful. Given that 2.0.0 clearly has a number of issues I think it's wise if we revert the changes of

https://github.com/TypeStrong/fork-ts-checker-webpack-plugin/pull/337/files

And release that as 3.0.0. This will ensure that people installing the plugin don't get broken. That's important. We don't want to frustrate users.

Would someone be up for raising that PR please? Please note this will be a breaking changes release as it's changing behaviour of the plugin. (Just as the change that took us from 1.6.0 to 2.0.0 was) Do remember to use yarn commit rather than git commit; it'll make your life easier! https://github.com/TypeStrong/fork-ts-checker-webpack-plugin/blob/594bed15a6915ff1693c4d65881823386d8d80ea/package.json#L49

We can experiment with re-introducing the changes of https://github.com/TypeStrong/fork-ts-checker-webpack-plugin/pull/337 subsequent to that.

Thanks!

Very strangely, this issue affected me with one entry point, but not another of the multi-compiler entries in the same build; both use typescript and the same tsconfig.json. But yes, can confirm that rolling back to <2.0.0 avoids the breakage.

3.0.0 should be out later today which will resolve this issue.

:tada: This issue has been resolved in version 3.0.0 :tada:

The release is available on:

Your semantic-release bot :package::rocket:

@johnnyreilly am I missing something, I thought this line is supposed to be reverted to .emit.tapAsync right? (based on this commit)

Just tried 3.0.0 and I still see the problem.

@piotr-oles @blacksteed232 @johnnyreilly same here, still just hangs after modules are handled.

Indeed, 3.0.0 still freezes.

Okay - let me take a look

Okay just force merged https://github.com/TypeStrong/fork-ts-checker-webpack-plugin/pull/353/files

A new release should appear with the fix in the next couple of hours. v3.0.1. Serves me right for merging in the middle of a sleepless night. Ah well.

:tada: This issue has been resolved in version 3.0.1 :tada:

The release is available on:

Your semantic-release bot :package::rocket:

Was this page helpful?
0 / 5 - 0 ratings