Disable static type checking for typescript

[tomitrescak]

NOT

Hi, I love how easy is to include typescript, but I was wondering whether it would be possible to disable static type checking and let only Babel strip types. The reasons are following:

1. In dev you are using external UI to compile and check types. This is doing the same work twice. This leads to point 2
2. Performance, I assume that this would decrease build and rebuild times
3. Refactoring. Often, during refactor I’d like to test partial functionality even when errors are present. Currently it’s all or nothing.

All and all I think static type check is great during build times, but at dev stage it comes in the way.

What do you think? Can you maybe point me to place where I could disable it? Thanks

[tanaypratap]

Going through the same problem. If you rewrite tsConfig.json it goes back to previous fixed format! Weird!

[td0m]

+1 for that.
I go into a lot more detail about this in #5820. Possible duplicate?

[lstkz]

My workaround:

• use react-app-rewired
• in config-overrides.js add

const path = require('path');

module.exports = function override(config) {
  config.plugins = config.plugins.filter(plugin => {
    return plugin.constructor.name !== 'ForkTsCheckerWebpackPlugin';
  });
  return config;
};

Full example

[dortamiguel]

My workaround:

• use react-app-rewired
• in config-overrides.js add

const path = require('path');

module.exports = function override(config) {
  config.plugins = config.plugins.filter(plugin => {
    return plugin.constructor.name !== 'ForkTsCheckerWebpackPlugin';
  });
  return config;
};

Full example

Looks like no longer works with latest, do you have any other alternative to this?

[freddi301]

https://create-react-app.dev/docs/advanced-configuration/#! ctr+f TSC_COMPILE_ON_ERROR

[ianschmitz]

Ah yes looks like we provided an escape hatch to satisfy this issue. Closing!

[tomitrescak]

@ianschmitz I disagree with closing this issue. The FLAG only allows to run the project on faulty compilation (and adresses only 1 out of 4 points raised).

It is still not possible to completely disable the compilation.

[ianschmitz]

We run the type checking asynchronous from the compile now. The impact should be low. If you can provide concrete examples of before/after time comparisons that show the type checking is negatively impacting build times I'd be happy to reconsider!

[maurealtrends]

In my case it impacts on development time. VSCode is already type checking the project and I hardly ever check the terminal for type errors. They're better displayed in the editor.
So the type checking is running unnecessarily twice.

[ianschmitz]

Understood. But are you experiencing slower compilation time as a result compared to if type checking was disabled? If not then I don't see the harm. If so then I would love to see comparison metrics to understand the cost in your specific project.

[maurealtrends]

My case might be more suitable for another "issue" then? Because the compilation time is not significantly impactful in my case.
Thank you in advance for your time.

[tomitrescak]

@ianschmitz as much as I appreciate the efforts you guys put into this project, I do not agree with this argument. The compilation is taking unnecessary resources, cpu, memory ... which on many machines are thin as it is. I explored my case and in my reasonably sized project the compiler takes 320mb of memory and jumps between 5-25% cpu time on my MB pro 2017.

Being a bit @ss about it, we can also let SETI run in the background since it will only marginally affect compilation time.

The CRA is already heavy as it is and some level of co figuration would be greatly appreciated.

[mgcrea]

I strongly agree with @tomitrescak here, if you use vscode, the ForkTsCheckerWebpackPlugin is redundant/useless and only slows down livereloading. In my opinion you should disable the plugin by default in dev mode unless configured otherwise (eg. with a "strict"-like option).

Currently bypassing this requires advanced fragile hacks (excluding ForkTsCheckerWebpackPlugin and nulling paths.appTsConfig).

Regarding the performance impact. In my small to medium sized monorepo (with roughly 100 ts files using a ts-enabled UI framework, ant-design, results are:

• Default: ~3s per save before reload (with ~1.5s waiting for typescript)
• Without redundant TS checks: ~1.5s

So roughly 100% performance penalty on every save!

---

react-app-rewired config-overrides.js repro:

module.exports = {
  // The Webpack config to use when compiling your react app for development or production.
  webpack(config, env) {

    // Drop noisy eslint pre-rule
    config.module.rules.splice(1, 1);

    // Drop noisy tslint plugin
    const EXCLUDED_PLUGINS = ['ForkTsCheckerWebpackPlugin'];
    config.plugins = config.plugins.filter(plugin => !EXCLUDED_PLUGINS.includes(plugin.constructor.name));
    return config;
  },
  // The paths config to use when compiling your react app for development or production.
  paths: function(paths, env) {
    // Disable react-scripts TypeScript handling
    paths.appTsConfig = '';
    return paths;
  }
};