If I have async: false, our webpack build (webpack-dev-serverwill not finish and just stuck atwait until bundle finished`
In v1.6.0, this does not happen.
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.
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
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!
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
style.scss or style.less import, then the plugin fails in async:false mode.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:
@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:
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: