No errors thrown while build running in the console.

[BiosBoy]

Current behavior

So, I've tried to use the fork-ts-checker-webpack-plugin in my project, but it doesn't throw any error even I put them for sure.

Expected behavior

Should throw errors if they are present in .ts|.tsx files processed by babel.

Steps to reproduce the issue

Example of the error to reproduce:

![error_image]: (https://i.ibb.co/r5HKHsv/Screen-Shot-2019-07-19-at-10-52-38-AM.png)

Everything is good on output anyway:

![output_image]: (https://i.ibb.co/94c2rFY/Screen-Shot-2019-07-19-at-10-54-18-AM.png)

Environment

• fork-ts-checker-webpack-plugin: 1.4.3
• typescript: 3.5.3
• tslint: 5.18.0
• webpack: 4.16.5
• os: Mojave OS/Mac

[phryneas]

That is just webpack output, the output of fork-ts-checker-webpack-plugin would be shown AFTER that. So my best guess is that it isnÄt running ? Can you share your webpack config?

[BiosBoy]

@phryneas Hi!

Here is my minimal webpack config:

const webpack = require('webpack')
const path = require('path')
const HtmlWebpackPlugin = require('html-webpack-plugin')
const UglifyJsPlugin = require('uglifyjs-webpack-plugin')
const ForkTsCheckerWebpackPlugin = require('fork-ts-checker-webpack-plugin');
const { BundleAnalyzerPlugin } = require('webpack-bundle-analyzer')
const debug = require('debug')('app:webpack:config')

const prodMode = process.env.NODE_ENV === 'production'

// ------------------------------------
// Rules
// ------------------------------------
const rules = []

// JavaScript / JSON
rules.push(
  {
    test: /\.(js|jsx|ts|tsx)?$/,
    exclude: [/node_modules|bower_components/],
    loader: 'babel-loader',
    query: {
      presets: ['@babel/react', '@babel/env', '@babel/typescript'],
      plugins: ['@babel/proposal-class-properties', '@babel/plugin-transform-object-assign', '@babel/plugin-syntax-dynamic-import']
    }
  }
)

const createConfig = options => {
  const paths = options.utils_paths
  const __DEV__ = options.globals.__DEV__
  const __PROD__ = options.globals.__PROD__
  const __TEST__ = options.globals.__TEST__

  debug('Creating configuration.')
  const webpackConfig = {
    mode: __DEV__ ? 'development' : 'production',
    entry: paths.client('main'),
    name: 'client',
    target: 'web',
    devtool: options.compiler_devtool,
    optimization: {
      splitChunks: {
        chunks: 'all',
        minChunks: 2
      },
      minimizer: [
        new UglifyJsPlugin({
          uglifyOptions: {
            compress: {
              unused: true,
              dead_code: true,
              warnings: false
            }
          },
          sourceMap: true
        }),
        new OptimizeCSSAssetsPlugin({})
      ]
    },
    performance: {
      hints: false
    },
    resolve: {
      modules: [paths.client(), 'node_modules'],
      extensions: ['.ts', '.tsx', '.js', '.jsx', '.json']
    },
    module: {}
  }

  // ------------------------------------
  // Entry Points
  // ------------------------------------
  // recommneded by babel to use instead of babel-polifill
  const appEnterPrefixPlugins = [path.resolve(__dirname, '../node_modules/core-js/stable'), path.resolve(__dirname, '../node_modules/regenerator-runtime/runtime')];
  const appPath = paths.client('main')
  const appEntryPoint = [...appEnterPrefixPlugins, appPath];

  webpackConfig.entry = {
    app: __DEV__ ? appEntryPoint.concat(`webpack-hot-middleware/client?path=${options.compiler_public_path}__webpack_hmr`) : appEntryPoint
  };

  // ------------------------------------
  // Bundle externals
  // ------------------------------------
  webpackConfig.externals = {
    react: 'React',
    'react-dom': 'ReactDOM'
  }

  // ------------------------------------
  // Bundle Output
  // ------------------------------------
  webpackConfig.output = {
    filename: '[name].[hash].js',
    path: paths.dist(),
    publicPath: options.compiler_public_path
  }

  // ------------------------------------
  // Plugins
  // ------------------------------------
  webpackConfig.plugins = [
    new webpack.DefinePlugin(options.globals)
  ]

  if (__TEST__) {
    debug('Enable plugins for live testing (HMR, NoErrors).')
    webpackConfig.plugins.push(new BundleAnalyzerPlugin())
  } else if (__DEV__) {
    debug('Enable plugins for live development (HMR, NoErrors).')
    webpackConfig.plugins.push(
      new HtmlWebpackPlugin({
        template: paths.client('index.html'),
        filename: 'index.html',
        inject: 'body',
        minify: {
          collapseWhitespace: true
        },
        chunksSortMode: 'auto'
      }),
      new webpack.HotModuleReplacementPlugin(),
      new webpack.NoEmitOnErrorsPlugin(),
      new ForkTsCheckerWebpackPlugin({
        tsconfig: '../../tsconfig.json',
        tslint: '../../tslint.json'
      })
    )
  } else if (__PROD__) {
    debug('Enable plugins for production')
    webpackConfig.plugins.push(
      new HtmlWebpackPlugin({
        template: paths.client(options.template),
        filename: options.template,
        minify: false,
        inject: false,
        chunksSortMode: 'auto'
      })
    )
  }

  webpackConfig.module.rules = rules

  return webpackConfig
}

module.exports.rules = rules

module.exports = createConfig

[BiosBoy]

@phryneas

would be shown AFTER that

The problem here is that it doesn't show any output after build at all.

[phryneas]

Hmm.

Could you make sure that you are running from the __DEV__ mode and also please pass absolute paths to the plugin options instead of relative paths? That might help narrow it down a bit.

[giniedp]

I'm having a similar issue, but i am still investigating to provide better input. However, here is my observation so far.

We are using ts-loader along with fork-ts-checker-webpack-plugin.
After introducing a compilation error, the error is not detected in a development mode but it it is detected in the production mode. The error output is missing in the development mode.

I suspect that in development mode the compilation on the main process is finishing faster than the type checker can do his work. The compilation is successfull, because in our case we use ts-loader with transpileOnly set to true.

Now in production mode webpack has a heavier load during compilation and so it probably takes longer and the type checker has a chance to complete his job and report the errors.

It's still just a quick guess deduced from a recent observation. Maybe someone can confirm or disproof my suspicion.

[johnnyreilly]

without a reliable repro it's hard to help. I suggest you take this setup here: https://github.com/TypeStrong/ts-loader/tree/master/examples/fork-ts-checker-webpack-plugin and try to reproduce the issue.

[giniedp]

i understand but can not reproduce it in a small setup so far and can not share the current project. Our setup involves

• thread-loader
• ts-loader with happyPackMode: true (which sets implies transpileOnly: true)
  and then ForkTsCheckerWebpackPlugin

However if i remove the thread-loader i get the output back again. According to @johnnyreilly post it seems to not being needed since Webpack 4. So we leave it out for now.

I checked our CI history and compared the commits where the behaviour occured the first time. Noticeable dependency changes were

• added html-webpack-plugin@^3.2.0
• added terser-webpack-plugin@1.2.4
• upgrade webpack 4.29.5 -> 4.32.2

But ts-loader@5.3.3, thread-loader@1.2.0, fork-ts-checker-webpack-plugin@0.4.15
did not receive any upgrade. Downgrading webpack did not fix the misbehaviour. So i checked changes in webpack config

Our old webpack config was exported as an object

module.exports = {
  // ...
}

the new config is exported as an array for parallel builds

module.exports = [{
  // ... monaco-editor web worker bundle
}, {
  // ... application bundle
}]

switching back to a single object export (just removing the monaco bundle) fixes the misbehaviour and the stats output and error log is back again.

As i said, i can not reproduce it in a small project. Tried to mimic the setup in https://github.com/TypeStrong/ts-loader/tree/master/examples/fork-ts-checker-webpack-plugin but had no lick so far.

[maksnester]

In my case, I can't see plugin output on the first run, because console is cleared. So I see only build result, like "Ok. Ready at: localhost:8080" but errors go before this printing. So I can see them later when I change some files and rebuild triggered...

[cmoad]

Also seeing this behavior. We recently cleaned up a ton of tslint warnings and I suspect the forked process is finished BEFORE the webpack process and the last process is winning the display.

[azizhk]

Same issue.
Can fork-ts-checker-webpack-plugin be used with babel-loader? I don't use ts-loader.

[phryneas]

Can fork-ts-checker-webpack-plugin be used with babel-loader? I don't use ts-loader.

It can - I'm using it with babel-loader.

Can you provide a reproducible?

[bfricka]

My issue looks the same as @giniedp
I'm running an ejected create react app, and I found the issue is that react-dev-utils has a bunch of stuff that swallows this up. Specifically, in the start script, WebpackDevServerUtils.createCompiler has a useTypeScript option, which I had omitted because I previously used a different method of compiling TS. However, I can't just enable that because it uses its own, old version of this plugin, so it'll be tapping something that will never be emitted.

I haven't figured out exactly how to handle this. I'll see if any of the newer versions are more permissive in not swallowing errors. If that doesn't work, I'll either fork it, or I'll just remove it completely and use const compiler = webpack(config). It won't have all the pretty stuff, but I'm not sure how much I care.

Not sure if the issue is actually the same, but if you're running a custom build script you might want to look into this.

[piotr-oles]

@BiosBoy , @giniedp , @maksnester , @cmoad , @azizhk , @bfricka
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 :)

[Aaron-Bird]

The same error when using version 5.0.1.
It works fine when returning to version 4.1.6.

[hejrobin]

Having the same issue, running ts-loader and fork-ts-checker-webpack-plugin@5.0.14.

Seems to completely ignore it at all (output from speed measure);

ForkTsCheckerWebpackPlugin took 0 secs

[marcin-kwiatkowski]

I am having a similar issue. @Aaron-Bird I can confirm that downgrading to version 4.x works. Did you solve your problem? I am a bit stuck and trying to understand what is happening in version 5.x so that it does not break the build command.

[johnnyreilly]

Are people experiencing this issue using webpack 5? I wonder if this is a common issue with webpack 5; there's something related logged against ts-loader: TypeStrong/ts-loader#1204

[marcin-kwiatkowski]

I dived into changelogs to see what has happened between 4.x and 5.x and I found out, at least it started working in my case.

new ForkTsCheckerWebpackPlugin({
      issue: {
        scope: 'all',
      },
    }),

What is the most interesting I also checked version 6 alpha and they say that the issue.scope has been removed at all.

To summarize:

For 4.x:

new ForkTsCheckerWebpackPlugin()

For 5.x:

new ForkTsCheckerWebpackPlugin({
      issue: {
        scope: 'all',
      },
    }),

For 6.x:

new ForkTsCheckerWebpackPlugin()

[piotr-oles]

I'm closing this as it's no longer an issue with the 6.0.0 version :)

[brett-east]

Just adding this in case anyone comes across this like I did.

ForkTsCheckerWebpackPlugin won't work nicely with an output with speed-measure-webpack-plugin when using webpack --watch. For me to get the output showing up again I had to remove SMP or use it conditionally, or not watch for file changes.

[Robbie-Cook]

Yeah, I just set async: false to the plugin, does the job:

new ForkTsCheckerWebpackPlugin({
  async: false,
}),