Very slow recompile times (~20 seconds) #9886
Comments
|
I have exactly the same problem. In a big TypeScript project (~1000 files) before upgrading to react-scripts@4 any code changes were applied immediately. Any combination of |
|
I have the same problem, it takes around 20 seconds each time it recompiles. It was not happening on 3.4.1 |
|
Same here, recompiles take several times as long as on 3.4.x |
|
Same here, I can't viably use 4.0.0 as it stands. Previously I'd get a reload of page in ~2 seconds after changing some code. Now takes ~45 seconds. Initial start time is also about 3-4x slower. |
|
Same here, Is there a way to solve this issue? |
|
Is anyone aware of a flag that can be set to make the |
|
Having the same issue here 💤
@FezVrasta not sure you can do that with a flag, but you can use patch-package to remove this line from react-scripts. UPDATE:I disabled the fast refresh using The outcome is the same... 👎 Anyone using a rewired cra that is experiencing this problem? |
I have your problem because I've used the react-app-rewired to customize the Create-react-app and I disabled the FAST_REFRESH but I got the same issue and every time I change my code, I have to wait for about 50 seconds to see my changes in the Browser. |
|
I believe the problem may be related to |
|
@jmcpeak It was my .eslintrc.js file that was making everything slow for me. This may not work for everyone but it worked for me. I ended up commenting out a few libraries from my extends list and now it is much faster: |
|
Same happening with a medium size project. Upgraded to v4 and its takes a bit more time to recompile. around 5-6s, |
|
I've also experienced slow recompile and the only "solution" which is of course not a solution, is to out-comment libraries/plugins. |
|
It may be a coincidence, but running |
|
Is there a way to completely remove ESLint from the dev compilation process? I believe many developers use ESLint as an IDE extension, so why do we need to duplicate it in react-scripts? I mean, every time developer saves a file, both IDE and react-scripts trigger their own ESLint process. For me, it would be useful to run the lint command explicitly only in two situations: before a commit ( |
|
I am experiencing the same thing. It takes about 20 seconds to recompile the files and on V4 which obviously is a problem. |
I second this wholeheartedly. I understand that CRA is meant to get new users up and going quickly along with enforcing good React code practices with But it also has another purpose, making a large portion of professional React projects not worry about sane configuration settings, bundling, builds, etc. I hand that work over to the smart folks running this project. I have a bizillion other things to worry about trying to deliver a quality product. Maybe switching |
|
I disabled (eslint requires a minimum of one file to work, I gave it test.js) And I had to rename my
|
|
In addition to the answer above, {
"eslint.options": {
"ignorePattern": ["!src/*"],
}
}So, in |
|
Same here, I've disabled However this "solution" is a bit dirty. |
|
Following a combination of @jmcpeak and @vlad-khitev-axon' s advice, I managed to fix the compiling issue. Compiling time is back to what it was before the migration to V4. This is obviously some kind of hack and it does feel dirty to mess with the eslint config as such. Hopefully ther will be a better way to do this in the future. In the meantime, kudos to the team for pushing v4 out. Besides this small issue the migration was very smooth and nothing else broke. |
|
It does not seem like eslint caching is enabled by default. It would be way faster when I updated options for new ESLintPlugin({
cache: true,
... |
|
Will the fix for this be released soon? This is currently blocking us from upgrading to cra v4 as it causes a 10x increase in compilation time on our project. |
|
@esetnik It has been added to the 4.0.1 milestone: https://github.com/facebook/create-react-app/milestone/78 |
|
For those still struggling with recompile speeds, one of the reasons it may be slower in v4 is because the lint will run on every compile using the config in your own custom Try running eslint across your whole codebase manually (with a cache) and see how much that takes, if this is the problem it should take about as long as your compiles take. There's a discussion here about being able to disable eslint runs on compile altogether, which makes sense if you have a custom In the meantime, I have personally disabled the eslint build using patch-package with this patch: diff --git a/node_modules/react-scripts/config/webpack.config.js b/node_modules/react-scripts/config/webpack.config.js
index eddca1b..3a895d1 100644
--- a/node_modules/react-scripts/config/webpack.config.js
+++ b/node_modules/react-scripts/config/webpack.config.js
@@ -750,7 +750,7 @@ module.exports = function (webpackEnv) {
// The formatter is invoked directly in WebpackDevServerUtils during development
formatter: isEnvProduction ? typescriptFormatter : undefined,
}),
- new ESLintPlugin({
+ isEnvProduction && new ESLintPlugin({
// Plugin options
extensions: ['js', 'mjs', 'jsx', 'ts', 'tsx'],
formatter: require.resolve('react-dev-utils/eslintFormatter'),That's not an ideal long term solution but better than the cumulative hours you'll spend waiting for eslint to run on every compile. |
|
Hey everyone, I tried all solutions here - changing my scripts version, adding the resolution at the end of the package.json, uninstalling, installing, every single suggestion in this thread I've tried it. Nothing seems to be working for me, is there anything I could try? Here is my package.json: I am using the absolute basic create-react-app that comes from the script directly, no modifications, no extra packages, nothing. Please someone help me. |
Change this last line from 2.3.0 to 2.4.1. Now it reloads fast when i make some changes on the code, but it does still (not sure if it was supposed to solve this too or not) take a very long time to start dev server. |
|
I and othe people (according to this issue) still struggling with very long time to start dev server. @ianschmitz is it possible to reopen this issue? |
|
Hey everyone, I managed to solve it. The problem was that I am on Windows and I am running WSL. Thanks for the help! |
|
If you got here & none of the solutions above have sorted your Issue, just fall back to the last best version that worked for you, I was using react
|
|
@castynet |
|
This might be an unpopular opinion but y'all are beating a dead horse here I'd say. It seems that the time is up for Create React App now that there's a way to migrate to and incrementally adopt Next.js which is far superior in my opinion. If I remember correctly, React core team supports Next.js initiative so there's probably not much motivation to keep supporting both projects proactively since there's a certain amount of functional overlap. PS: I am in no way affiliated with Next or Vercel. This is just my personal take so please take it with a grain of salt. |
|
Thanks for the suggestions. |
|
lol @mareksuscak yes next.js may be far superior for web, but CRA still has a lot of value if you are not aiming for web, take an example, if i want to compile my app and contain it with cordova to run on mobile, you can do that with ease on cra, but with nextjs that is not possible. So imo it's two completely different solutions. |
|
@PaulPCIO fair enough. I acknowledge my response does not cover all of the possible use cases and it wasn't my goal anyway. I was responding to the majority who use CRA on the web. There may be more alternatives for some of us than others. My point still stands, though. From my perspective, this project could greatly benefit from onboarding more proactive maintainers who can review and merge pull requests from its large open-source community and overall manage this project. I believe that's what's causing all delays and ostensible lack of interest or motivation. I don't want to offend any active members so please don't hate me for saying this out loud. This is just my current perspective. |
|
This is also in line with my observations. |
|
@mareksuscak I do agree with you though in using nextjs when it is possible as a solution, about 80% of my projects run on nextjs and vercel, but yea still has that 20% percent that is dependant on cra. It would be created to see the same interactivity from the cra team as nextjs. Both teams have been innovative but yea nextjs takes the cake if you count the progress they made and the excellent dev experience they provide 🖥️ and same this is just my personal opinion. 😉 |
|
I just found out that on |
|
@aprilmintacpineda That's a nice move. Really reduced the compile time |
|
I cut down my HMR update time a lot by using craco to have a custom start script which disables ESLint without disabling it anywhere else (editor, husky git hooks, or any other tooling). Install:
module.exports = {
eslint: {
enable: false
}
}
"scripts": {
"start": "craco start",
"start:eslint": "react-scripts start",
"build": "react-scripts build",
"lint": "eslint . --max-warnings 0"
}I will check out Next.js though. Maybe it's worth switching, i've used Next.js before, and only went with CRA because i didn't need any backend for my current project. |
|
I'm using windows and yarn start is taking more than 15 minutes to run craco start |
|
Adjust node_modules/react-scripts/config/webpack.config.js as mentioned here: #9886 (comment) in my case change: arround line 764
to
You can auto patch the package using patch-package as i deed: npx patch-package react-scripts |
|
Greetings, i was using "react-scripts": "5.0.1". For development server it is taking high ram consumption of 3-4GB. After a single change system RAM is increasing to 5 GB and the server is stopping on complete RAM consumption, saying |
|
Somehow, switching from |
|
CRA is dead. Jest will die soon as well IMO. From your wd: git apply --directory=node_modules/react-dev-utils path/to/patchOf course you can add a flag instead using diff --git a/WebpackDevServerUtils.js b/WebpackDevServerUtils.js
index 9dda650ee..e75a2320a 100644
--- a/WebpackDevServerUtils.js
+++ b/WebpackDevServerUtils.js
@@ -17,8 +17,6 @@ const prompts = require("prompts");
const clearConsole = require("./clearConsole");
const formatWebpackMessages = require("./formatWebpackMessages");
const getProcessForPort = require("./getProcessForPort");
-const typescriptFormatter = require("./typescriptFormatter");
-const forkTsCheckerWebpackPlugin = require("./ForkTsCheckerWebpackPlugin");
const isInteractive = process.stdout.isTTY;
@@ -141,25 +139,23 @@ function createCompiler({
if (useTypeScript) {
compiler.hooks.beforeCompile.tap("beforeCompile", () => {
- tsMessagesPromise = new Promise((resolve) => {
- tsMessagesResolver = (msgs) => resolve(msgs);
- });
+ tsMessagesPromise = Promise.resolve();
});
- forkTsCheckerWebpackPlugin
- .getCompilerHooks(compiler)
- .receive.tap("afterTypeScriptCheck", (diagnostics, lints) => {
- const allMsgs = [...diagnostics, ...lints];
- const format = (message) =>
- `${message.file}\n${typescriptFormatter(message, true)}`;
-
- tsMessagesResolver({
- errors: allMsgs.filter((msg) => msg.severity === "error").map(format),
- warnings: allMsgs
- .filter((msg) => msg.severity === "warning")
- .map(format),
- });
- });
+ // forkTsCheckerWebpackPlugin
+ // .getCompilerHooks(compiler)
+ // .receive.tap('afterTypeScriptCheck', (diagnostics, lints) => {
+ // const allMsgs = [...diagnostics, ...lints];
+ // const format = message =>
+ // `${message.file}\n${typescriptFormatter(message, true)}`;
+
+ // tsMessagesResolver({
+ // errors: allMsgs.filter(msg => msg.severity === 'error').map(format),
+ // warnings: allMsgs
+ // .filter(msg => msg.severity === 'warning')
+ // .map(format),
+ // });
+ // });
}
// "done" event fires when webpack has finished recompiling the bundle.
@@ -176,11 +172,11 @@ function createCompiler({
// https://github.com/facebook/create-react-app/issues/4492#issuecomment-421959548
const statsData = stats.toJson({
all: false,
- warnings: true,
+ warnings: false,
errors: true,
});
- if (useTypeScript && statsData.errors.length === 0) {
+ if (false && useTypeScript && statsData.errors.length === 0) {
const delayedMsg = setTimeout(() => {
console.log(
chalk.yellow(
@@ -188,7 +184,6 @@ function createCompiler({
)
);
}, 100);
-
const messages = await tsMessagesPromise;
clearTimeout(delayedMsg);
if (tscCompileOnError) {
|
|
This is even easier diff --git a/WebpackDevServerUtils.js b/WebpackDevServerUtils.js
index 9dda650ee..02bb745b2 100644
--- a/WebpackDevServerUtils.js
+++ b/WebpackDevServerUtils.js
@@ -111,6 +111,8 @@ function createCompiler({
tscCompileOnError,
webpack,
}) {
+ // kill TS dev errors and warnings
+ useTypeScript = false;
// "Compiler" is a low-level interface to webpack.
// It lets us listen to some events and provide our own custom messages.
let compiler; |
|
all work for me after add typescript in devDependencies (recompile times in (~7 seconds) my package.json bellow |
and others
Describe the bug
(Write your answer here.)
Hi, I'm trying to upgrade from 3.4.1 to 4.0.0 but I noticed that when I make a change it takes approx 20 seconds to recompile. With 3.4.1 it's just a couple of seconds.
Did you try recovering your dependencies?
I deleted node_modules, yarn.lock, and installed the deps.
Which terms did you search for in User Guide?
(Write your answer here if relevant.)
Slow, compile time, recompile.
Environment
Steps to reproduce
(Write your steps here:)
yarn startExpected behavior
The recompile time should be almost instantaneous. It also takes a lot of time to start the first time (after
yarn start)Actual behavior
(Write what happened. Please add screenshots!)
The app takes 20 seconds to recompile.
Reproducible demo
(Paste the link to an example project and exact instructions to reproduce the issue.)
Not available, I think it's related to the size of my app (It's 1012 files)
The text was updated successfully, but these errors were encountered: