webpack-dev-server@3.4.1 ignores changes in node_modules

[Sayan751]

• Operating System: Windows (Server 2019)
• Node Version: 10.15.0
• NPM Version: 6.4.1
• webpack Version: 4.32.2
• webpack-dev-server Version: 3.4.1

• [x] This is a bug
• [ ] This is a modification request

Code

// main/webpack.config.js
const HtmlWebpackPlugin = require('html-webpack-plugin');
const baseUrl = "/";

/** @type {() => import("webpack").Configuration} */
module.exports = () => ({
    plugins: [
        new HtmlWebpackPlugin({
            template: "index.ejs",
            metadata: { baseUrl }
        })
    ]
})

// main/src/index.js
const {Service} = require("service"); // a dependency from a local node module

const div = document.createElement("div");
div.innerText = new Service().method();

document.querySelector("body").appendChild(div);

Expected Behavior

When any changes occur in the node_modules, webpack-dev-server should trigger a new build.

Actual Behavior

It is not happening after I upgraded to the latest webpack-dev-server@3.4.1. With the earler version of 3.3.1 it was working perfectly. If the fix is non-trivial, are there better workarounds rather than pinning the version?

For Bugs; How can we reproduce the behavior?

I have created the repo https://github.com/Sayan751/webpack-reloading-issue to demonstrate this problem. The steps to reproduce the problem is detailed there.

For Features; What is the motivation and/or use-case for the feature?

[hiroppy]

Do you resolve if you add [] to watchOptions.ignored?

[Sayan751]

Yup this solved the issue. Thank you.

[Sayan751]

I have seen the issue https://github.com/webpack/webpack-dev-server/issues/1781. However, the motivation behind this default exclusion is not very clear to me. Can you please elaborate? I am little bit concerned about any pitfalls of watching the changes in node_modules, though I am using similar workflow for years now for creating webapps, without any hiccup.

[alexander-akait]

@Sayan751 watching node_modules is overhead in many cases and can throw error in some cases because node_modules can have many files

Why you need watch node_modules?

[Sayan751]

@evilebottnawi I see your point. I think it is a specific requirement for the workflow I follow.

I use Aurelia for the web app development. And there lies small limitation of loading symlinked files correctly. That's why I use a small watch script to deploy the dist content of the local module to the main webpack app. This workflow helps a lot during development. Though I cannot site any evidence, I think that the workflow should not be that uncommon for large apps.

I am using this workflow for quite a sometime now. That's why when it broke after a minor update of webpack-dev-server, I was bit surprised.

[alexander-akait]

Thanks for answer we think about it in near future, you can have solution right now

[Garethp]

I'd like to second this bug, and make some suggestions. Personally I've used the node_module watching for debugging issues in third party libraries quickly, as well as for a couple of web applications that I've built where shared code is linked in and it's a lot more convinient to make quick changes just to see if they work rather than having to restart webpack-dev-server.

With that being said, I think a large part of this problem is documentation. Despite the default being changed and changing behavior that's been around for quite a while, it's not mentioned in the 3.4.0 release notes, or even in the documentation for watchOptions.ignored. Since this is a relatively new change, it's not easy to Google to find out the answer.

I understand the point of the change, and it seems like a positive one, but I think it would be great if the change and workaround could be put into the documentation of webpack-dev-server as well as the release notes.

[alexander-akait]

@Garethp Thanks for feedback, we will do this in future

[alexander-akait]

/cc @hiroppy what do you think about revert this commit?

[hiroppy]

My answer is https://github.com/webpack/webpack-dev-server/pull/1794#issuecomment-496809056. I think we should revert this...

[alexander-akait]

@hiroppy yes, let's do it

[blieque]

As mentioned on the commit, I think resolving symlinks before excluding node_modules/ could work. That said, if there is no significant performance difference, I'd support rolling the change back.

[NexxLuo]

When i use yarn link and changed the files with symlinks , the webpack compiled successfully , but get a message shown '[WDS] Nothing changed' . That's why?When i change the symlinks to true, will get an error 'exports is not defined'.

My config look like this:

module.exports = { stats: "detailed", watchOptions: { ignored: [] }, resolve: { symlinks: false, alias: {}, extensions: [".wasm", ".mjs", ".js", ".json", ".jsx", ".ts", ".tsx"] } }