You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
When I yarn upgrade a package I have to restart create-react-app server #2956
When I run yarn upgrade package-name-xxx, I need to restart the dev server in order to see those changes.
Here are steps to reproduce. (Note the following example uses a an npm package I made, https://github.com/tnrich/semver-console , that just console logs its semver number when required.)
Note: The bulk of this issue was already in a comment in #2606
This is quite a pain point for us because we use a lot of linked npm packages when developing our app and the start up time is quite slow for create-react-app.
Any help getting this resolved would be greatly appreciated. Thanks!
Is no one else experiencing this? I spend a significant chunk of time restarting my CRA server every day. I can look into fixing this if someone points me in the right direction.
@gaearon that plugin sadly just watches for missing dependencies at compile time, that is after a file in user-land has changed.
In this case, when you add/remove/update a dependency a recompilation should be issued, so I see no other options than properly watching node_modules..
Oh, I remember now. That plugin only handled the case where you forget to install a package and it gets stuck saying "module not found". It probably didn't handle reinstalls/updates.
In this case, when you add/remove/update a dependency a recompilation should be issued, so I see no other options than properly watching node_modules..
We can try that and then exclude some bad cases (e.g. .cache). Want to look into it?
@maciej-ka it should be possible to use webpack's internal watcher, just by tweaking its "ignore" config to watch e.g. package.json files inside node_modules.
@EnoahNetzach can you post some example code for what needs to be done to get it to stop ignoring those files? This issue still bothers me all the time
The idea could be to update the ignoredFiles function in order to not ignore the package.json files inside the node_modules.
If there were lookahead support in node < 9, there would be as simple as adding .+(?<!\/package\.json)$ at the end of that RegExp (look here, in the unit tests area), but in this case a solution could be to return an array (it is compatible with anymatch APIs) with the current regex and something like a function to test that the filename doesn't end with package.json.
Then webpack would theoretically recompile as soon as any package.json gets changed (new lib, new lib's version, deleted lib)
There is a way to mimic lookahead with (?!.*package\.json$) (end of input anchor is critical here). But webpack doesn't observe package.json files (unless they are implicitly imported), so tweaking ignoredFiles, from my experience, will not help. For more details, I would love to invite you to related PR in progress: #3936
Is there any movement or workarounds on this? This is very time consuming when working with locally linked packages as every singe change requires a react app restart. Maybe worth seeing how angular handles this live reloading out of the box?
For anyone stumbling across this issue the problem stems from react-scripts/config/webpackDevServer.config.js
// Reportedly, this avoids CPU overload on some systems.
// https://github.com/facebook/create-react-app/issues/293
// src/node_modules is not ignored to support absolute imports
// https://github.com/facebook/create-react-app/issues/1065
// Commented to fix node_modules not recompiling
watchOptions: {
ignored: ignoredFiles(paths.appSrc),
},
You could eject and comment out the watch option (or remove them) but I did not want to eject.
My workaround was to use to use the customize-cra `watchAll function:
Rather than watching package.json to trigger rebuilds, it makes more sense to watch the lockfiles (e.g. yarn.lock or package-lock.json).
This is helpful for cases where you're installing packages from e.g. GitHub, where your package.json might have "bar": "@foocorp/bar" but your lockfile will contain the exact commit hash at the time of install.
Calling yarn upgrade bar in this case will check for a new version on the main branch of @foocorp/bar, install it, and update the lockfile (which may now have new sub-dependencies installed as well).
Activity
tnrich commentedon Aug 30, 2017
@gaearon
Is no one else experiencing this? I spend a significant chunk of time restarting my CRA server every day. I can look into fixing this if someone points me in the right direction.
Thank you!
gaearon commentedon Jan 8, 2018
Please investigate if you can. This code was supposed to protect against it.
EnoahNetzach commentedon Jan 19, 2018
@gaearon that plugin sadly just watches for missing dependencies at compile time, that is after a file in user-land has changed.
In this case, when you add/remove/update a dependency a recompilation should be issued, so I see no other options than properly watching
node_modules..gaearon commentedon Jan 19, 2018
Oh, I remember now. That plugin only handled the case where you forget to install a package and it gets stuck saying "module not found". It probably didn't handle reinstalls/updates.
We can try that and then exclude some bad cases (e.g.
.cache). Want to look into it?maciej-ka commentedon Jan 29, 2018
If using node's
fs.watchand writing something similar to WatchMissingPlugin sounds like a correct plan, I would give it a try.Rebuild project on package update (react#2956)
EnoahNetzach commentedon Jan 30, 2018
@maciej-ka it should be possible to use webpack's internal watcher, just by tweaking its "ignore" config to watch e.g.
package.jsonfiles insidenode_modules.tnrich commentedon Feb 7, 2018
@EnoahNetzach can you post some example code for what needs to be done to get it to stop ignoring those files? This issue still bothers me all the time
EnoahNetzach commentedon Feb 14, 2018
webpack has an "ignore" config in watch mode, which accepts anymatch patterns (regex/globs/functions).
The idea could be to update the
ignoredFilesfunction in order to not ignore thepackage.jsonfiles inside thenode_modules.If there were lookahead support in node < 9, there would be as simple as adding
.+(?<!\/package\.json)$at the end of thatRegExp(look here, in the unit tests area), but in this case a solution could be to return an array (it is compatible with anymatch APIs) with the current regex and something like a function to test that the filename doesn't end withpackage.json.Then webpack would theoretically recompile as soon as any
package.jsongets changed (new lib, new lib's version, deleted lib)maciej-ka commentedon Feb 14, 2018
There is a way to mimic lookahead with
(?!.*package\.json$)(end of input anchor is critical here). But webpack doesn't observepackage.jsonfiles (unless they are implicitly imported), so tweaking ignoredFiles, from my experience, will not help. For more details, I would love to invite you to related PR in progress: #3936aharris commentedon Nov 6, 2019
Is there any movement or workarounds on this? This is very time consuming when working with locally linked packages as every singe change requires a react app restart. Maybe worth seeing how angular handles this live reloading out of the box?
aharris commentedon Nov 7, 2019
For anyone stumbling across this issue the problem stems from
react-scripts/config/webpackDevServer.config.jsYou could eject and comment out the watch option (or remove them) but I did not want to eject.
My workaround was to use to use the
customize-cra`watchAll function:Create
config-overrides.jsand add:SevenZark commentedon Dec 6, 2019
I gave this a try, but it didn't have any effect for me. Is there some other step I'm missing? Is this still working for you?
abhinav-TB commentedon Jul 23, 2020
This is a serious issue that consumes developer time, I would like to work on it if someone could guide me
namuol commentedon Aug 15, 2020
Rather than watching
package.jsonto trigger rebuilds, it makes more sense to watch the lockfiles (e.g.yarn.lockorpackage-lock.json).This is helpful for cases where you're installing packages from e.g. GitHub, where your
package.jsonmight have"bar": "@foocorp/bar"but your lockfile will contain the exact commit hash at the time of install.Calling
yarn upgrade barin this case will check for a new version on the main branch of@foocorp/bar, install it, and update the lockfile (which may now have new sub-dependencies installed as well).mrmckeb commentedon Jun 16, 2021
This is expected behaviour, but we'd recommend looking at something like nodemon to help manage situations like this.