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

Created on 14 Aug 2017  路  14Comments  路  Source: facebook/create-react-app

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 [email protected])
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 https://github.com/facebookincubator/create-react-app/issues/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!

up for grabs! medium bug

Most helpful comment

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

All 14 comments

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

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

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

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

@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

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)

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: https://github.com/facebook/create-react-app/pull/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:

$ 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()
  )
};
$ 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?

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

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

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ericvicenti picture ericvicenti  路  83Comments

rovansteen picture rovansteen  路  192Comments

daviseford picture daviseford  路  108Comments

gaearon picture gaearon  路  86Comments

jantimon picture jantimon  路  154Comments