Use NamedModulesPlugin for HMR debugging

[weaverryan]

When using HMR, the name of your module shows up in the console. By default, since numbers are used, it looks like:

[HMR] Updated modules:
[HMR]  - 21
[HMR]  - 241

After:

[HMR] Updated modules:
[HMR]  - ./node_modules/css-loader/index.js?sourceMap!./node_modules/vue-loader/lib/style-compiler/index.js?{"vue":true,"id":"data-v-504ecf1c","scoped":true,"hasInlineConfig":false}!./node_modules/vue-loader/lib/selector.js?type=styles&index=0!./app/Resources/assets/vuejs/components/Hello.vue
[HMR]  - ./node_modules/style-loader/addStyles.js

... which at least makes a bit more sense :).

This adds a bit more logic:

1. In dev, always add NamedModulesPlugin. We actually only need this if you're using HMR... but I don't think there's a disadvantage of including it always, so I've done it to try to keep the dev environment as consistent as possible with itself.

2. In prod, we only add HashedModuleIdsPlugin when versioning is enabled. We could at it always (for consistency), but it slightly increases the size of the built assets, because the module ids are longer.

3. Enable WebpackChunkHash only when versioning is used, because it's the only time we use the [chunkhash]

[stof]

Can we have a way to turn it ON otherwise too ? If you use query-string versioning with https://packagist.org/packages/incenteev/hashed-asset-bundle, having a stable file hash is important too.

[stof]

maybe a .useStableModuleNames() method, which is enabled automatically when using versioning ?

[weaverryan]

@stof Unless you enable versioning, your output filenames will always be static and not changing (e.g. main.js). This just controls the internal names used for the modules. Or am I missing a detail? Basically, I don't think the module naming scheme should be important externally.

[stof]

@weaverryan my issue is stable module names, not stable output file names.

hashed-asset-bundle uses a (truncated) hash of the file content as version. So if you use numeric index for modules, the hash of the vendor module may change just because of reindexing module, busting the cache for nothing.

you use the HashedModuleIdsPlugin when versioning is enabled to ensure that the chunkHash stay consistent, but we have the same need when using hashed-asset-bundle.
I don't care about how modules are named. I care that vendor modules don't get renamed randomly between 2 deployments where only the app code changed and not vendors.

[weaverryan]

@stof Ah, I totally understand now. I've updated the PR to always use one of the plugins, instead of adding a new option. Regardless of where you do versioning, it seems like an edge case to me to "be ok with" your asset contents often changing... even when you didn't make any code changes to it. So, at the cost of a slight increase in asset size (in one example I saw, the asset size went from 296kb to 300kb), I'd like to be consistent and always give this "expected" behavior. If someone later really wants to minimize their asset size at the expense of the content sometimes changing, they can make a request (and we can add a method to allow that to be configured). This feels like a more sensible default to me.

[stof]

@weaverryan fine with me

[stof]

useless check. It will always be set

[stof]

you could put this directly above instead of using a moduleNamePlugin variable.

[stof]

I would say when not production instead of putting an operator in the middle of an English sentence

[stof]

shouldn't this use a windows path on windows ?

[weaverryan]

it doesn't matter here, because it's not what I'm testing for. I just need a path that won't cause the code to throw an exception internally (Unable to determine contentBase option...) - and that logic for that exception is tested elsewhere with the proper paths. We could probably clean this file up a bit with some mocks.

[weaverryan]

pff, nevermind - I immediately saw the test failure after posting this. I'm trying a Windows path now to see if it'll keep things happy :)