Closed dortamiguel closed 5 years ago
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:
allowJS
to true
and add checkJS: false
..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
)git status
) and manually strip out any TypeScript type information.https://create-react-app.dev/docs/advanced-configuration/#! ctr+f TSC_COMPILE_ON_ERROR
@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.
I will like to disable typescript type checking to improve loading time.
I found the following example to disable typescript
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