React-app-rewired: How I can disable typechecking when usint typesctipt with CRA?

Created on 4 Aug 2019  路  8Comments  路  Source: timarney/react-app-rewired

I will like to disable typescript type checking to improve loading time.

I found the following example to disable typescript

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

  return config;
};

But if I add that the client gets stuck on a message Files successfully emitted, waiting for typecheck results... forever. There is an actual way of disabling this?

I'm using

"react-scripts": "3.0.1",
"react-app-rewired": "^2.1.3",

Most helpful comment

All 8 comments

I'm not entirely sure what needs to be done to resolve this issue, but I did find the relevant code in the CRA repo: https://github.com/facebook/create-react-app/blob/1548a0a92e41f9f626aa2c5226fb1a2cb2ec9229/packages/react-dev-utils/WebpackDevServerUtils.js#L182-L210

I don't think you can, because they've hard-coded it into the build process outside of the webpack config as @with-heart has shown. One of the reasons for using ForkTsCheckerWebpackPlugin is so that it can be run as a separate process rather than blocking the main compilation thread (i.e. runs in parallel), though running it separately currently only occurs on a development build (a production build would not stop on type errors if the type checking was run separately - I've used the plugin with the old react-scripts-ts in the past). See https://github.com/facebook/create-react-app/blob/1548a0a92e41f9f626aa2c5226fb1a2cb2ec9229/packages/react-scripts/config/webpack.config.js#L615-L636 for the current configuration settings for the plugin. The other reason for running ForkTsCheckerWebpackPlugin is that babel does not do type checking _at all_ - it simply strips out the types entirely when compiling. See https://devblogs.microsoft.com/typescript/typescript-and-babel-7/

You could potentially enable the async setting for Production mode so that it also runs in parallel by setting the async value to true.

You could also reduce the amount of typechecking being done (in both modes) - CRA turns on syntactic checks as well. This would mean changing the checkSyntacticErrors option to false. Have a read on these two options at https://www.npmjs.com/package/fork-ts-checker-webpack-plugin#options

Example:

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

  if (forkTsPlugin) {
    // Check this, it may be forkTsPlugin.xxx.async - do a console.log(forkTsPlugin) to check structure
    forkTsPlugin.async = true;
    forkTsPlugin.checkSyntacticErrors = false;
  }

  return config;
};

The other question is - do you genuinely wish to allow errors in use in a production build (e.g. passing a string to a number parameter) that can cause runtime errors when deployed? That's what you're letting through when you disable type checking, and raises the question of why you're using typescript instead of javascript when you don't actually want type checking occurring? How long is the type checking taking in your build?

I have a CI and I run tsc --noEmit to check if I have any type error, so Im never going to be able to commit a type error on master.

I have an slow computer and my fans are quite noisy, removing things that makes the development faster really helps.

Also I like on dev sometimes to ignore some types to see if something works.

By the way, do you now about any other thing I can disable that will make the dev mode faster?

I tried the checkSyntacticErrors = false but it's ignored.

Those are the only ones I can see that could possibly speed up the type checking part of compiling. With the checkSyntacticErrors, what output do you get if you do the following:

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

  if (forkTsPlugin) {
    console.log(JSON.stringify(forkTsPlugin, undefined, 2));
    throw new Error('stopping compiling here to read the console.log content');
  }

  return config;
};

Note: the project will not actually compile with the above because of the thrown Error - that's actually so that CRA doesn't clear the console.log content from the screen so you can read it. I'm particularly interested in the structure of the plugin logged - I suspect that the options may be contained inside a field inside the plugin (e.g. forkTsPlugin.options.checkSyntacticErrors) instead of directly (e.g. forkTsPlugin.checkSyntacticErrors). The full path to the checkSyntacticErrors option should be visible in the log message. Note also that this only disables some of the type checking, not all of it - there isn't a way I can see at present to disable all of it because CRA has written/added its own compilation plugin for webpack that causes the webpack build to hang if the forkTsChecker plugin doesn't report that it has completed typechecking, and that CRA plugin isn't able to be modified/removed through the webpack config.

I found how to disable typescript type checking! 馃榾

const { paths: rewiredPaths } = require('react-app-rewired');
const { scriptVersion } = rewiredPaths;
const paths = require(`${scriptVersion}/config/paths`);

module.exports = {
  webpack: (config) => {
    // Disable eslint
    config.module.rules.splice(1, 1);

    // Disable type checking
    paths.appTsConfig = undefined;

    return config;
  },
};

I'm not entirely sure how much this applies but I was able to disable typechecking on a Ignite Bowser app by using these steps:

  1. In tsconfig.json, change allowJS to true and add checkJS: false.
  2. Run the following commands in your project root to rename your .ts and .tsx files to .js:
    A. find . -name "*.ts" -exec bash -c 'mv "$1" "${1%.ts}".js' - '{}' \;
    B. find . -name "*.tsx" -exec bash -c 'mv "$1" "${1%.tsx}".js' - '{}' \; (on this one you may want to rename to jsx though -- for React Native it's just js)
  3. Go through all the files that were renamed (easy to tell by doing git status) and manually strip out any TypeScript type information.

@freddi301 Thank you for adding the info on the new option to the issue. Please note that the option hadn't existed yet when the issue was created 6-7 months ago though.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

brendonco picture brendonco  路  3Comments

windhost picture windhost  路  5Comments

InsOpDe picture InsOpDe  路  5Comments

001123 picture 001123  路  4Comments

srhise picture srhise  路  5Comments