When I yarn upgrade a package I have to restart create-react-app server

[tnrich]

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.)

In terminal tab #1:

(using latest version of create-react-app@1.3.3)
create-react-app yarn-upgrade-test
cd yarn-upgrade-test/
yarn start

In terminal tab #2:

yarn add semver-console@0

At the top of yarn-upgrade-test/src/App.js add:

import "semver-console";

in the browser console you'll now see:

SEMVER: 0.0.0

In terminal tab #2 run:

yarn upgrade semver-console@1

in the browser console you'll still see:

SEMVER: 0.0.0

instead of the expected

SEMVER: 1.0.0

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!

[tnrich]

@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]

Please investigate if you can. This code was supposed to protect against it.

[EnoahNetzach]

@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]

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]

If using node's fs.watch and writing something similar to WatchMissingPlugin sounds like a correct plan, I would give it a try.

[EnoahNetzach]

@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.

[tnrich]

@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]

webpack has an "ignore" config in watch mode, which accepts anymatch patterns (regex/globs/functions).

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)

[maciej-ka]

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

[aharris]

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]

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:

$ yarn add customize-cra react-app-rewired --dev

Create config-overrides.js and add:

const {
  overrideDevServer,
  watchAll
} = require("customize-cra");

module.exports = {
  webpack: override(
    // usual webpack plugin
    watchAll()
  ),
  devServer: overrideDevServer(
    // dev server plugin
    watchAll()
  )
};

[SevenZark]

$ yarn add customize-cra react-app-rewired --dev

Create config-overrides.js and add:

const {
  overrideDevServer,
  watchAll
} = require("customize-cra");

module.exports = {
  webpack: override(
    // usual webpack plugin
    watchAll()
  ),
  devServer: overrideDevServer(
    // dev server plugin
    watchAll()
  )
};

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]

This is a serious issue that consumes developer time, I would like to work on it if someone could guide me

[namuol]

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).

[mrmckeb]

This is expected behaviour, but we'd recommend looking at something like nodemon to help manage situations like this.