Fork-ts-checker-webpack-plugin: Build stops after `0.95 'emitting' 'fork-ts-checker-webpack-plugin'`

[bitttttten]

Current behavior

My webpack build gets to 95%, and after it emits 'fork-ts-checker-webpack-plugin' the build fails. Although the command exits with status 0, like a success, no build artefacts are generated. With the webpack logs, I see that it only ever gets to 95%, at this step.

yarn build
yarn run v1.19.1
$ node ./scripts/build_client.js
Ready to start the build.

Creating an optimized production build...
0 'compiling'
0.1 'building' '0/0 modules' '0 active' ''
0.1 'building' '0/1 modules' '1 active' 'multi /home/circleci/project/src/index.tsx'
0.10120000000000001 'building' '1/1 modules' '0 active' ''
...
0.930392156862745 'after chunk asset optimization' 'SourceMapDevToolPlugin'
0.9352941176470588 'asset optimization'
0.9401960784313725 'after asset optimization'
0.9450980392156862 'after seal'
0.95 'emitting'
0.95 'emitting' '@loadable/webpack-plugin'
0.95 'emitting' 'HtmlWebpackPlugin'
0.95 'emitting' 'GenerateSW'
0.95 'emitting' 'fork-ts-checker-webpack-plugin'

This is the end of the logs, no artefacts are outputted. That is the build folder is empty.

Expected behaviour

The build continues to 100% and the artefacts are outputted.

Steps to reproduce the issue

I am using a forked version of CRA, but I just run yarn build and get this situation.

Here is a sample from my config. Full config is here.

const ForkTsCheckerWebpackPlugin = require("react-dev-utils/ForkTsCheckerWebpackPlugin");

new ForkTsCheckerWebpackPlugin({
  typescript: resolve.sync("typescript", {
    basedir: paths.appNodeModules
  }),
  async: isEnvDevelopment,
  useTypescriptIncrementalApi: true,
  checkSyntacticErrors: true,
  resolveModuleNameModule: process.versions.pnp
    ? `${__dirname}/pnpTs.js`
    : undefined,
  resolveTypeReferenceDirectiveModule: process.versions.pnp
    ? `${__dirname}/pnpTs.js`
    : undefined,
  tsconfig: paths.appTsConfig,
  reportFiles: [
    "**",
    "!**/__tests__/**",
    "!**/?(*.)(spec|test).*",
    "!**/src/setupProxy.*",
    "!**/src/setupTests.*"
  ],
  watch: [paths.appServer, paths.appSrc],
  silent: true,
  // The formatter is invoked directly in WebpackDevServerUtils during development
  formatter: isEnvProduction ? typescriptFormatter : undefined
});

Environment

• fork-ts-checker-webpack-plugin: react-dev-utils/ForkTsCheckerWebpackPlugin ("react-dev-utils": "^9.0.1",)
• typescript: "typescript": "3.4.5",
• webpack: "webpack": "4.29.6",
• os: circleci

[yuya-kanai]

I have the same issue with nuxt (vue)

[bitttttten]

It is definitely reproducible, as I can trace it back to a commit where the issue starts to happen.

Although VSCode does not complain, linting has no issues, and the TypeScript playground does not have a problem with it either. Or when building locally.

Very strange how only the CI server has issues running it, and then even stranger is that I can SSH into the CI machine and manually run the build.. and then it works 😅

[johnnyreilly]

as I can trace it back to a commit where the issue starts to happen.

Would you be able to do some investigation to discover what the issue is please?

[ypresto]

Maybe useTypescriptIncrementalApi: false can solve the issue:
https://github.com/TypeStrong/fork-ts-checker-webpack-plugin/issues/330#issuecomment-532166555
(Today I bumped fork-ts-checker-webpack-plugin from 0.5.2 to 3.1.1 (and bumped typescript from 3.5.3 to 3.7.4) and webpack build did not finish, then solved with this option.)
TL;DR: It's too complex for tsc to emit type declaration of our project, which is necessary for incremental type checking (but I didn't use webpack --watch).

[johnnyreilly]

Maybe useTypescriptIncrementalApi: false can solve the issue:

That's not really a long term fix as we plan to remove that option once all the kinks in the useTypescriptIncrementalApi are ironed out

[yangfan-coder]

也许useTypescriptIncrementalApi: false可以解决问题：
＃330（评论）
（今天我将fork-ts-checker-webpack-plugin从0.5.2更改为3.1.1（并将打字稿从3.5.3更改为3.7.4），并且webpack的构建没有完成；然后使用此选项解决。）
TL; DR：对于tsc来说，发出我们项目的类型声明太复杂了，这对于增量类型检查是必须的（但我没有使用webpack --watch）。
Excuse me ，useTypescriptIncrementalApi Where to set up

[johnnyreilly]

I'm really sorry I didn't understand that

[yangfan-coder]

I'm really sorry I didn't understand that

I want to disable during packaging 【fork-ts-checker-webpack-plugin】
But I don't know how to do it

[johnnyreilly]

I need a little more context I think; I don't see fork-ts-checker-webpack-plugin being used in a packaging context. More for type checking in building / bundling web apps

[yangfan-coder]

我认为我需要更多背景信息；我没有看到在打包上下文中使用fork-ts-checker-webpack-plugin。用于构建/捆绑Web应用程序的类型检查的更多内容

I want to disable the ts check when packing
`
nuxt.config.js
import ForkTsChecker from 'fork-ts-checker-webpack-plugin';

build: {
/*
** You can extend webpack config here
*/
postcss: {
preset: {
autoprefixer: {
overrideBrowserslist: [
'Android 4.1',
'iOS 7.1',
'Chrome > 31',
'ff > 31',
'ie >= 8'
]
}
}
},
vendor: ['axios'],
// loaders: {
// ts: {
// transpileOnly: false
// }
// },
// analyze: true,
plugins: [
new ForkTsChecker({
useTypescriptIncrementalApi: false
})
],
publicPath: conf.build.assetsPublicPath
// extend(config, ctx) {
// if (ctx.isDev && ctx.isClient) {
// config.module.rules.push({
// enforce: "pre",
// test: /.(js|vue)$/,
// loader: "eslint-loader",
// exclude: /(node_modules)/,
// options: { fix: true }
// });
// }
// }
}

`

[johnnyreilly]

I think just comment it out; the plugin is there for type checking. If you don't need to use it then don't use it

[yangfan-coder]

I think just comment it out; the plugin is there for type checking. If you don't need to use it then don't use it

But I still check when I don't use packaging
I'm upset about this

[johnnyreilly]

Perhaps use webpack's mode to determine when you want to use it and not?

[berickson1]

FWIW, I was tracking this issue as well. I had been seeing this on CircleCI builds in production. I had seen a hint that it _may_ have been related to a poorly (or unreported) out of memory exception inside of webpack.
After upgrading to the latest build of webpack and related build tooling, the issue seems to have resolved itself.

[yangfan-coder]

nuxt.config.js
So I closed the typescript check
buildModules: [ [ '@nuxt/typescript-build', { typeCheck: false } ] ]

[johnnyreilly]

Thanks for sharing @berickson1 - perhaps worth trying @yangfandashuaige?

[bryanrideshark]

I am also experiencing this issue using @storybook/angular on a Circle.CI process.

Ideally would like to disable this plugin as part of the Webpack used by Storybook. Unsure as to what caused the error, but it's the same for me; Gets to 95% and then dies.

[GreenGremlin]

This recently started happening in our circle-ci builds. The build that was having issues was using a single shell script to perform a number of tasks, one of the last being running webpack. I ended up solving this by breaking the shell script up into separate circle steps.

[GreenGremlin]

Never mind, it looks like that didn't work after all.

[GreenGremlin]

I was finally able to track down! Turns out there's two different out of memory errors you can run into for node processes, in a docker container on circleci. The first is if an individual process exceedes the limit imposed by node via the --max_old_space_size option. In that case, node kills the process and throws an OOM exception that is pretty obvious. fork-ts-checker-webpack-plugin actually detects the kill signal for this and alerts you. The second is if you set the --max_old_space_size value too high and the overall memory usage of the docker container surpasses the 4GB limit imposed by circleci. In this case docker starts silently killing processes. It seems to kill them with a SIGINT, but it doesn't seem to throw any type of OOM exception, as far as I can tell, so the process just silently dies. I was able to fix this by setting the memory limit for both webpack and fork-ts-checker-webpack-plugin to 1400MB.

[johnnyreilly]

Thank you for sharing your findings @GreenGremlin !

[GreenGremlin]

Might be worth adding a warning when the service exits with a SIGINT signal. Maybe something like, "Type checking and linting interrupted - If running in a docker container, this may be caused by the container running out of memory. If so, try increasing the container's memory limit or lowering the memoryLimit value in the ForkTsCheckerWebpackPlugin configuration."

[GreenGremlin]

Here's a PR to warn for this condition: https://github.com/TypeStrong/fork-ts-checker-webpack-plugin/pull/398

[piotr-oles]

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

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot :package::rocket: