Server doesn't reload module after the second module update.

[PavelTurk]

Bug report

I have two projects a and b. Project b uses project a with this way:

"dependencies": {
    "@foo/a": "^0.1.0",
    ...
 },

In project b .npmrc I have

@foo:registry=http://localhost:4873

To get the bug the following steps are required:

• In project b: npm run serve -- --port 8888
• In project a - some modifications, code building, uploading it to registry.
• In project b: npm update @foo/a - everything is OK
• In project a - some modifications, code building, uploading it to registry.
• In project b: npm update @foo/a - ERROR:

Compiled with problems:
ERROR in ./node_modules/@foo/a/dist/index.common.js
Module build failed (from ./node_modules/babel-loader/lib/index.js):
Error: ENOENT: no such file or directory, open '/home/pavel/b/node_modules/@foo/a/dist/index.common.js'

However, I checked, this file '/home/pavel/b/node_modules/@foo/a/dist/index.common.js exists and is not broken.
So, the problem is that after the first npm update server works, however, after the second one it doesn't.

Actual Behavior

Module must be updated after 2,3,4 ...N cases.

Expected Behavior

Server must processes all module updates not only the first one.

How Do We Reproduce?

Follow the steps above with any project.

Please paste the results of npx webpack-cli info here, and mention other relevant information

  Webpack-dev-server:  4.7.4. 

  System:
    OS: Linux 5.11 Ubuntu 20.04.3 LTS (Focal Fossa)
    CPU: (8) x64 AMD Ryzen 5 1400 Quad-Core Processor
    Memory: 1.79 GB / 15.59 GB
  Binaries:
    Node: 17.3.0 - /usr/bin/node
    Yarn: 1.22.17 - /usr/bin/yarn
    npm: 8.3.0 - /usr/bin/npm
  Browsers:
    Firefox: 95.0.1
  Packages:
    less-loader: 7.3.0 => 7.3.0 
    sass-loader: ^10.0.0 => 10.2.1 
    vuetify-loader: ^2.0.0-alpha.0 => 2.0.0-alpha.9 
    webfontloader: ^1.0.0 => 1.6.28

[alexander-akait]

You should not run updates in node_modules when you in dev mode, otherwise you should set empty array here https://webpack.js.org/configuration/other-options/#managedpaths due https://github.com/webpack/webpack/blob/main/lib/config/defaults.js#L381

It is perf improvement in webpack v5

[PavelTurk]

@alexander-akait I am sorry, I am really a beginner in webpack. Do I understand you correctly - there is no way to update module while webpack server is running? And if I need to update module, I always should stop the server, update module and start server again?

[alexander-akait]

Yes or you can mark node_modules as mutable (using the option above), but it is bad for perf, I recommend to avoid it

[PavelTurk]

@alexander-akait Following your advice I added the following to my config:

    config.snapshot = {
      managedPaths: [path.resolve(__dirname, '../node_modules')],
      immutablePaths: [],
      buildDependencies: {
        hash: true,
        timestamp: true,
      },
      module: {
        timestamp: true,
      },
      resolve: {
        timestamp: true,
      },
      resolveBuildDependencies: {
        hash: true,
        timestamp: true,
      },
    };

However, it didn't help. Server sees only the first module update, but doesn't see next ones. Could you say, if this is a bug or I do something wrong? Please, note, that webpack server performance is not important for me as I don't use JS web servers in production.

[alexander-akait]

Set managedPaths on [] and remove other options

[PavelTurk]

@alexander-akait This is my new config:

config.snapshot = {
        managedPaths: []
};

However, result is the same. Server handles only the first module update and ignores all following updates..

[alexander-akait]

Please create reproducible test repo

[PavelTurk]

@alexander-akait You can check it with any project where one and more dependencies.

[alexander-akait]

@PashaTurok I asked example, because I can't reproduce

[PavelTurk]

@alexander-akait Ok, I will do repo with tests, but a little bit later.

[alexander-akait]

Thanks

[PavelTurk]

@alexander-akait This is a full test with detailed readme. Thank you.

[alexander-akait]

hm, I can't reproduce it without @vue/cli-service, I think a problem somewhere in @vue/cli-service, we don't use magic here, just watch files and rebuild on changes (note - for node_modules and other modules directory we use cache and you can control it using managedPaths), so if no changes - no reload, you can look at code and found we don't have any logic for handling fs changes except send a websocket message, can you check timestamp of /home/pavel/b/node_modules/@foo/a/dist/index.common.js?

Also I strongly recommend do not use bundled common/umd version of library - just setup ts to emit ecma modules and use them, otherwise you lost a lot of optimizations

[PavelTurk]

@alexander-akait Thank you very much for your time, help and suggestions. Then I will add this information to vue-cli project.