Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

webpack-dev-server@3.4.1 ignores changes in node_modules #1934

Closed
1 of 2 tasks
Sayan751 opened this issue May 29, 2019 · 13 comments · Fixed by #1970
Closed
1 of 2 tasks

webpack-dev-server@3.4.1 ignores changes in node_modules #1934

Sayan751 opened this issue May 29, 2019 · 13 comments · Fixed by #1970

Comments

@Sayan751
Copy link

  • 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
  • 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
Copy link
Member

hiroppy commented May 29, 2019

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

@Sayan751
Copy link
Author

Yup this solved the issue. Thank you.

@Sayan751
Copy link
Author

I have seen the issue #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
Copy link
Member

@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
Copy link
Author

Sayan751 commented May 29, 2019

@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
Copy link
Member

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

@Garethp
Copy link

Garethp commented May 31, 2019

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
Copy link
Member

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

@alexander-akait
Copy link
Member

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

@hiroppy
Copy link
Member

hiroppy commented Jun 5, 2019

My answer is #1794 (comment). I think we should revert this...

@alexander-akait
Copy link
Member

@hiroppy yes, let's do it

@blieque
Copy link

blieque commented Jun 5, 2019

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.

hiroppy added a commit that referenced this issue Jun 5, 2019
hiroppy added a commit that referenced this issue Jun 5, 2019
@NexxLuo
Copy link

NexxLuo commented Dec 5, 2020

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"] } }

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants