Doesn't read the memoryLimit from tsconfig.json

[nickretallack]

Current behavior

I created a react app using create-react-app. I put a memoryLimit setting in the tsconfig.json file like so:

{
  "compilerOptions": {
    "target": "es5",
    "lib": [
      "dom",
      "dom.iterable",
      "esnext"
    ],
    "allowJs": true,
    "skipLibCheck": true,
    "esModuleInterop": true,
    "allowSyntheticDefaultImports": true,
    "strict": true,
    "forceConsistentCasingInFileNames": true,
    "module": "esnext",
    "moduleResolution": "node",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "noEmit": true,
    "jsx": "react"
  },
  "include": [
    "src"
  ],
  "memoryLimit": 99999
}

I put a very large amount of typescript files in the project.
I ran yarn start, and it built the app but then this happened:

Files successfully emitted, waiting for typecheck results...
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
...
Writing Node.js report to file: report.20200309.174515.68.0.001.json

I opened the report and I saw this:

    "commandLine": [
      "/usr/bin/node",
      "--max-old-space-size=2048",
      "/go/src/github.robot.car/cruise/gulp/client/node_modules/fork-ts-checker-webpack-plugin/lib/service.js"
    ],

That's not the memory limit I set! So I edited node_modules/react-scripts/webpack.conf.js directly to add a memoryLimit to the ForkTsCheckerWebpackPlugin constructor directly, like so:

        new ForkTsCheckerWebpackPlugin({
          memoryLimit: 99999,
          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.*',
          ],
          silent: true,
          // The formatter is invoked directly in WebpackDevServerUtils during development
          formatter: isEnvProduction ? typescriptFormatter : undefined,
        }),

Then I ran yarn start and it succeeded in type checking my project.

Expected behavior

I'd like to be able to configure the memory limit without having to eject from create-react-app or patch the react-scripts package. I'd think that configuring it in the tsconfig.json file would work since it's already passing that configuration to the plugin anyway.

Steps to reproduce the issue

I'm sure you can debug this issue by simply creating a react app with create-react-app --typescript foo, adding a memoryLimit to your tsconfig.json file, and then adding a debug statement to check if your plugin is respecting that memory limit.

Issue reproduction repository

Environment

• fork-ts-checker-webpack-plugin: 3.1.1
• typescript: 3.5.3
• tslint: none?
• webpack: 4.41.5
• os: Ubuntu 18.04

[piotr-oles]

Sorry @nickretallack but it's not a bug - it's how this plugin works and how it is documented. We don't want to extend tsconfig.json with our custom configuration because it can cause configuration parsing error on the TypeScript. What we could eventually implement is a separate configuration file, like .fork-ts-checker.json. I'm not an expert on create-react-app - maybe you could ask there if it's possible to pass configuration to this plugin without ejecting create-react-app?

[piotr-oles]

@nickretallack
Please check the new alpha release of the plugin: https://github.com/TypeStrong/fork-ts-checker-webpack-plugin/tree/v5.0.0-alpha.1 As I promised, it supports cosmiconfig configuration - it's documented in the README.md :)

[nickretallack]

Cool, thanks. Honestly we ended up commenting out this plugin because it would stop development if there were any type errors, and we just converted our whole project from flow so we have about 8000 type errors. Instead, we've been running tsc and writing the result to a checked-in file and treating it as a baseline until we can reduce the number of errors. We review the error delta in code reviews to ensure we aren't adding new errors. When the project is greener, we may start using this plugin again.