webpack-dev-server recompiles all files when using webpack array of configuration

Created on 12 Sep 2018  路  14Comments  路  Source: webpack/webpack-dev-server

webpack-dev-server when used with array of webpack configuration - it recompiles all the file instead of file that was affected.

For example, if I have webpack config as below:

var path = require("path");
var webpack = require("../../");
module.exports = [
    {
        name: "mobile",
        // mode: "development || "production",
        entry: "./src/mobile",
        output: {
            path: path.join(__dirname, "dist"),
            filename: "mobile.js"
        },
        plugins: [
            new webpack.DefinePlugin({
                ENV: JSON.stringify("mobile")
            })
        ]
    },

    {
        name: "desktop",
        // mode: "development || "production",
        entry: "./src/desktop",
        output: {
            path: path.join(__dirname, "dist"),
            filename: "desktop.js"
        },
        plugins: [
            new webpack.DefinePlugin({
                ENV: JSON.stringify("desktop")
            })
        ]
    }
];

From above example - Any change in src/mobile/index.js, will result in recompilation/rebuild of desktop.js as well. I expect the webpack-dev-server should recompile just the file that has changed (mobile.js). I am using array of configuration with 15 - 20 output files, which really slows down the incremental build process.

I tried using lazy and cache mode option of webpack-dev-server but it doesn't seem to help. Am I missing any configuration option here?

3 (important) patch 4 (inconvenient) bug

All 14 comments

On a similar note - I'm not getting live-reloading with multiple configs. I get the rebuild when looking at the terminal, but the browser doesn't refresh (if I manually refresh, I do see the changes).

I'm happy to file a separate issue but I'm wondering if this is specifically due to multiple configs or some other bug... does live-reload work for you in this case?

Nevermind - my issue is fixed by _not_ having the manual entry point added as suggested at https://stackoverflow.com/a/41223040/784519

Removing that fixed things - though it could be that I had it added to all the configs whereas it would have worked if only added to the first _shrug_

Are we working on resolving the issue webpack/webpack-dev-middleware#338?

@KenilDomadia First we should find where this happens and why

@evilebottnawi I've described the scenario for when this happens in the description of the issue. By "where this happens", do you mean the line of code where this happens? I haven't look into webpack-dev-server code until now. I can get started if you want to me to trace the lines of code.

@KenilDomadia

By "where this happens", do you mean the line of code where this happens?

Yes

I haven't look into webpack-dev-server code until now. I can get started if you want to me to trace the lines of code.

Feel free to start this. Some busy right now.

/cc @KenilDomadia problem still exists?

@evilebottnawi Problem still exists. I can make a reproducible test repo if you want, but it is basically the config provided above. If you change mobile.js, it will recompile the desktop bundle as well. This behavior does not happen with webpack in watch mode.

Edit: Tested with webpack-dev-middleware and the problem occurs there as well (both are recompiled when only one changes).

Edit 2: Actually, it looks like when the source of one is changed, they do not both recompile. But with webpack-dev-server and webpack-dev-middleware, it prints out the old compilation data for the bundle that did not change again. So the hash is the same, and the compilation time is the same as the first compilation for the bundle that did not change, just printed again. Keep this issue open in case I missed something though.

As you can see (output from webpack-dev-middleware, but illustrates the same point), I edited desktop.js once, and this was the output. You can see mobile.js hash and compilation time are exactly the same both times, because I did not change it.
output

hm, maybe we should don't output stats for compilation what is not recompiled :smile: but i think it is bad idea

In my observation compilation of each entry is still triggered when one of them changes and it leads to very slow compilation times. Currently it takes about 8 seconds for 10 entries (one per "page" similar to MPA approach suggested in Webpack docs) each time I save just one file which is, of course, unacceptable.
Each entry "require"'s single Elm file and that's, probably, Elm compilation which takes that long, but, still, it just should not require all 10 bundles to recompile if I change line of code in a file which is not even shared across them. Elm loader is wise enough to only recompile what's changed so, apparently, it is being instructed doing complete recompilation for each of 10 bundles each time and I would definitely want to see this resolved.

Any chance for it to get resolved soon if I provide a test repo?

@szubtsovskiy maybe somethign changes in your bundle, for example you can use Provide plugin and include timestamp on each compilation, so webpack can't cache you bundle(s), anyway please provide minimum reproducible test repo

@evilebottnawi Thanks for the quick response. I keep investigating things myself for the time being and discovered that problem is apparently neither in webpack-dev-server nor in webpack-dev-middleware as I installed a Webpack plug-in which does not use them and still get the same behaviour.
I will try to hunt down the issue and report it to the proper repo if it is not my config which causes these troubles.

Feel free to any feedback

Was this page helpful?
0 / 5 - 0 ratings

Related issues

mrdulin picture mrdulin  路  3Comments

tulika21-zz picture tulika21-zz  路  3Comments

daryn-k picture daryn-k  路  3Comments

da2018 picture da2018  路  3Comments

MJ111 picture MJ111  路  3Comments