Webpack Dev Server not reporting errors on subsequent recompile

[JoshRobertson]

This issue has come up during our upgrade to v5. It wasn't an issue in v4. We use babel's preset for typescript via the babel-loader for webpack.

Consider a basic type error
const x: number = "word"; //Type '"word"' is not assignable to type 'number'.ts(2322)

On initial compile with the webpack dev server, this correctly throws an error.

TS2322: Type '"word"' is not assignable to type 'number'.
  > 40 |     const x: number = "word";
       |           ^
ℹ ｢wdm｣: Failed to compile.

However, on a subsequent file save (with the same error still present), the dev server reports a successful compile despite the error still existing.

ℹ ｢wdm｣: Compiled successfully.

webpack.config.js

new ForkTsCheckerWebpackPlugin({
  eslint: undefined,
  async: false,
  issue: { scope: "webpack" },
  formatter: "codeframe",
  logger: { infrastructure: "silent", issues: "console" },
  typescript: {
    enabled: true,
    configFile: path.resolve(__dirname, "..", "..", "tsconfig.local.json"),
    diagnosticOptions: { syntactic: true, semantic: true, declaration: false, global: false },
    mode: "write-references",
    build: false,
    profile: false,
    memoryLimit: 2048,
  },
});

tsconfig.local.json

  "compilerOptions": {
    "allowJs": true,
    "allowSyntheticDefaultImports": true,
    "declaration": false,
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "esModuleInterop": true,
    "forceConsistentCasingInFileNames": true,
    "importsNotUsedAsValues": "preserve",
    "lib": ["ES2020", "dom"],
    "module": "ES2020",
    "moduleResolution": "node",
    "sourceMap": true,
    "skipLibCheck": true,
    "target": "ES2019",
    "jsx": "react",
    "noUnusedLocals": true,
    "baseUrl": ".",
  },
  "include": ["app/javascript/**/*"],
  "exclude": ["node_modules"],
  "compileOnSave": true

Environment

• @babel/preset-typescript: 7.10.4
• babel-loader: 8.1.0
• fork-ts-checker-webpack-plugin: 5.0.7
• typescript: 3.9.6
• eslint: 7.4.0
• webpack: 4.43.0
• webpack-dev-server: 3.11.0

[johnnyreilly]

Closing as duplicate of #36

Please note there's a workaround in that thread that may be worth trying. Fascinating to hear that this wasn't an issue with v4 but is with v5! I was actually under the impression that with v4 it was an issue too.

cc @piotr-oles

[JoshRobertson]

@johnnyreilly I'm not sure this is a duplicate of that issue. My issue is not limited to type-only files, this happens in our React components.

Also, compilation is running on subsequent file saves, it's just reporting a false negative (saying successful when an error still exists).

[JoshRobertson]

Noticeable, when I set async: true it doesn't even report it the first time.

[johnnyreilly]

cc @piotr-oles - perhaps not a duplicate

[piotr-oles]

Does this error occur for scope: "all" setting?

[JoshRobertson]

Does this error occur for scope: "all" setting?

yes, scope: "all" has the same issue unfortunately.

[JoshRobertson]

@piotr-oles I found the problem! We had our webpack config wrapped in speed-measure-webpack-plugin and it seems that the issue is connected to that plugin, because when I remove it from our config, the TS Checker reports errors correctly on subsequent recompiles.

[JoshRobertson]

In the event anyone else needs it, this is the config we use in development that is working correctly with webpack-dev-server. This also solved our issue with async: true not working.

const tsCheckerPlugin = new ForkTsCheckerWebpackPlugin({
  eslint: {
    files: "./app/javascript/**/*.{ts,tsx,js,jsx}",
  },
  async: true,
  issue: { scope: "webpack" },
  formatter: "codeframe",
  logger: { infrastructure: "silent", issues: "console" },
  typescript: {
    enabled: true,
    configFile: path.resolve(__dirname, "..", "..", "tsconfig.local.json"),
    diagnosticOptions: { syntactic: true, semantic: true, declaration: false, global: false },
    mode: "write-references",
    build: false,
    profile: false,
    memoryLimit: 2048,
  },
});

[piotr-oles]

Thanks! That's very interesting - I will try to investigate why there was such a conflict :)