Does not work when chunkName is not identical with what babel plugin generates when using flushChunkNames()

I am trying to break down a few issues in all these packages to try to improve docs or just understand it better on my own.

One thing I noticed is that the chunkName I assign in options has direct influence on the file names being produced - I figure that’s used for the [name] part of the chunkFilename. That makes one thing quite unfortunate: the output matches the file structure and naming of the sources e.g. when importing ./views/main/Main the chunkName generated by the Babel-Dual-Import-Plugin is views/main/Main which produces and output inside the build folder of views/main/Main.js+css.

What I like to have instead is a flat structure of files inside the build directory. I assumed that I can just change the chunkName part inside the universal options but unfortunately this does not work. It even breaks - without any warning. It just seems to be unable to match the chunkNames to the files correctly and ignores the affected universal module.

Interestingly it seems to be possible to fix at the this last issue by using flushModuleIds() instead of flushChunkNames() from the server part of this library. I wonder why we chose one or another.

[faceyspacey]

…by the way i reverted back to my previous thing (which was the second thinking in the grand scheme of things) to use chunkNames. The reasons are:

• since babel-plugin-universal-import provides all options there is now less risk of you writing the wrong chunkName option
• flushModuleIds require extra webpack config to make IDs deterministic (hashedModuleIds and namedModuleIds plugins)
• there is a bit more server work using flushModuleIds
• seeing proper names for files rather than 0.js makes it easier for developers to know the system is working. With numbered chunks you are less likely to know if the correct chunk was served.

The cons are:

• nested directories, but that’s a matter of perspective. I prefer it. It shouldn’t really matter if you automate all this stuff.
• i dont like dealing with the magic comment in the babel-plugin implementation, but this shouldn’t be a driving factor.
• if not using the babel-plugin u can easily mess up how u provide the chunkName option and the webpackMode comment

The cons ultimately are less significant and after the PR to webpack it’s clear to me that webpack is focusing on the chunkName strategy. It’s working solidly in all places. We should start using it. The interface of a magic comment sucks in my opinion. Automated is the correct way, and guess what, we do that!

We have the unique luxury to do that whereas webpack itself doesnt since it doesn’t handle rendering. Because we handle rendering we can remove all chunk naming from the user’s hands.

When universal-render comes out next week, you will no longer flush chunk names from react-universal-component. u just will just flush chunks and all will happen for you.

[faceyspacey]

I’ll think of something tho. New angles always open up