You receive a TS6305 error when using the fork-ts-checker-webpack-plugin. The error does not show up when not using the plugin. Running the build again without running a cleanup script to remove the output directory and buildinfo file will result in a no error being outputted. See the steps to reproduce for more info.
You either receive this error consistently when using or not using the plugin, or don't receive the error at all.
https://github.com/mvargeson/fork-ts-checker-webpack-plugin-resolution-issue#how-to-reproduce
https://github.com/mvargeson/fork-ts-checker-webpack-plugin-resolution-issue
I did a little bit of digging into this and I think it's a race condition when building.
I believe this stems from fork-ts-checker and ts-loader running in parallel. Typescript composite projects rely on the dist files being emitted and on disk, so if fork-ts-checker starts typechecking a module that ts-loader hasn't emitted yet, the above error would likely occur. That also explains why running build a second time resolves the issue (since the older files are already on disk). This could potentially result in changes not being type-checked if on-disk files were stale.
I don't have any concrete evidence to back this up but I think it's plausible...
@mvargeson , @berickson1
Please try fork-ts-checker-webpack-plugin@alpha - I've published a new version which should resolve this issue 馃殌
I will close this issue to clean-up the backlog. If this release didn't solve the issue, we can re-open this :)
@piotr-oles - Tried this on 5.0.0-alpha.14 and it seems to resolve this issue. Thanks!
Note: I did run into #433 when testing this
cc: @mvargeson
Most helpful comment
I did a little bit of digging into this and I think it's a race condition when building.
I believe this stems from fork-ts-checker and ts-loader running in parallel. Typescript composite projects rely on the dist files being emitted and on disk, so if fork-ts-checker starts typechecking a module that ts-loader hasn't emitted yet, the above error would likely occur. That also explains why running build a second time resolves the issue (since the older files are already on disk). This could potentially result in changes not being type-checked if on-disk files were stale.
I don't have any concrete evidence to back this up but I think it's plausible...