Named chunks ignoring names when requiring modules at runtime

[brenwell]

Hey guys, firstly webpack is great.

I am having some trouble with code splitting. I am trying to have 2 named chunks for two routes in my application which are not often visited. mysite.com/settings and mysite.com/access.

here is my webpack.config.coffee

module.exports =

  contentBase: "#{__dirname}/src/"

  cache: true

  entry:
    app: './src/coffee/app'
    head: './src/coffee/head'

  output:
    path: path.join(__dirname, 'build')
    publicPath: '/'
    filename: '[name].js'
    chunkFilename: '[name]-[chunkhash].js'

  plugins: []

And here is my router.coffee

access: (slug) ->
    _this = @
    require.ensure ['../view/page/access-page.coffee'], (require) ->
      AccessPage = require '../view/page/access-page.coffee'
      accessPage = AccessPage.getInstance()
      accessPage.render() unless accessPage.isRendered
      _this.showPage accessPage
    , 'access'


settings: (slug) ->
    _this = @
    require.ensure ['../view/page/settings-page.coffee'], (require) ->
      SettingsPage = require '../view/page/settings-page.coffee'
      settingsPage = SettingsPage.getInstance()
      settingsPage.render() unless settingsPage.isRendered
      _this.showPage settingsPage
    , 'settings'

I am not using the webpack dev-server, instead I am watching simply by using the following cmd-line tool

webpack -d --progress --colors --watch

The problem is that it ignores the names when requiring the files, as you can see the format is '[name]-[chunkhash].js' it generates files with the correct format e.g. settings-2j3nekj2n3ejkn2.js but during development, when I attempt to load the page, the browser complains that '-2j3nekj2n3ejkn2.js' cannot be found, somehow the mapping of the files, ignores the names. If I leave out the names, then it works.

Generated files

Chrome error

So the question is how can I setup mulitple named chunks correctly (or is there a bug). Thanks in advance.

Note I have checked out their examples in the docs at https://github.com/webpack/docs/wiki/code-splitting

and I have followed their optimization docs aswell at https://github.com/webpack/docs/wiki/optimization

and I also posted the question on stackoverflow
http://stackoverflow.com/questions/24743114/webpack-multiple-named-chunks-ignoring-names-at-runtime

But I am still stuck

[jhnns]

Guessing from the documentation your config should be using output.namedChunkFilename. And apparently there is no chunkhash when using namedChunkFilename ( @sokra ?)

  output:
    namedChunkFilename: '[name]-[hash].js'

[brenwell]

Hey thanks for the reply.

I has also thought maybe that was the case, but apparently that is for entry chunks, which mine aren't.

I tried it anyway and it works but not as expected.

here is the new config

module.exports =

  contentBase: "#{__dirname}/src/"

  cache: true

  entry:
    app: './src/coffee/app'
    head: './src/coffee/head'

  output:
    path: path.join(__dirname, 'build')
    publicPath: '/'
    filename: '[name].js'
    # chunkFilename: '[chunkhash].js'
    namedChunkFilename: '[name]_[hash].js'

here are the generated files

And here is the chrome network

As you can see it creates files 2..js & 3..js again no names.

Sadly I am still stuck here

[jhnns]

Ok, that's something for @sokra 😁

[brenwell]

Thanks anyway @jhnns. @sokra if you have any ideas, I am all ears.

[sokra]

It's pretty simple: [name] is not supported for chunkFilename and chunkFilename is used for chunk loading. namedChunkFilename is not used (it's pretty old and has no real usecase).

We should propably remove namedChunkFilename and add support for [name] to chunkFilename. That's pretty easy.

I assume your app works fine if you simply omit the [name] in chunkFilename.

[brenwell]

Thanks for the reply.

Yes, that all makes sense.

• I noticed that [name] is not in the documentation. Strangely [name] is acknlowedged in the file creation of the chunkFilename files. That's what throw me off.
• I couldn't quite understand the use case of namedChunkFilename so I m pleased to hear that you also don't
• Adding support for [name] to chunkFilename would be fantastic especially considering the following:

The docs say the following are supported

output.chunkFilename
The filename of non-entry chunks as relative path inside the output.path directory.

[id] is replaced by the id of the chunk.

[hash] is replaced by the hash of the compilation.

[chunkhash] is replaced by the hash of the chunk.

Yes it works when I remove the the [name] however only with the [chunkhash]

With [hash] it breaks because [hash].js writes to the same file name, thus writing over the previously generated chunk. So [hash] is only useful when combined with either [chunkhash] or [id]

Which makes it slightly hard to identify the chunk. '[name]-[hash].js' would be a great format because it would allow identifiable chunk files which can share a single hash for easy revisioning.

What do you think?

[sokra]

Why do you want identifiable chunk filenames? You can use the stats to identify the files.

[brenwell]

I have a couple reasons, but I would be happy to hear a better way to do it

1. I am using charles and I want to be able to easily see what chunk was requested without having to look at its contents. Most of my chunks are page related, so they are easy to name.
2. Because of the following https://github.com/webpack/docs/wiki/optimization#single-page-app. I want to be able to serve my index.html with the appropriate chunk, in order to prevent 2 round trips. I am aware that I can make entry chunks, but I actually want to keep one main entry chunk, and then just load the other chunks according to the route. (maybe this won't work. I haven't got that far)
3. General debugging

[brenwell]

Fantastic, how does process work for commits to become part of the npm package.

Basically what I am trying to ask is, how can I get this awesomeness today?

Thanks alot.

[sokra]

yes, you can use it now...

I publish every commit to master as fast as possible within a beta version (beta in the version string). When I have a good feeling that it's fine I publish a more stable version (no beta in the version string). If you want to use the stable version add something like ~1.2 to your package.json. If you like bleeding edge stuff ^1.3.2...

[brenwell]

Super, thanks again Sokra!

[brenwell]

Works great!

[jhnns]

👍 @sokra for fast npm publish

[ghost23]

Just stumbled upon this. The docs do not yet reflect the change right? I would be willing to update them, if that's OK.