Webpack.js.org: output.chunkFilename cannot be a function

[webpack-bot]

Bug report

What is the current behavior?
When using a function for output.chunkFilename, this error is returned:

configuration.output.chunkFilename should be a string.

What is the expected behavior?

As per the docs, configuration.output.chunkFilename can be a function.

I would expect this to work in the same way as an output.filename function:

config.output.filename = info => '[name].bundle.js'

Version

| library | version
| ---------------- | -------
| Webpack | 4.6.0

---

This issue was moved from webpack/webpack#7090 by @ooflorent. Original issue was by @CLL80.

[ooflorent]

Quoting Tobias:

Please fix the docs. For technical reasons it must be a string.

[gabaum10]

Question: if this is true, how can you determine if you need one chunk to skip the hash, and the rest to have the hash? The problem is we're loading one single common file first, before any of the other entry files in a JSP which doesn't konw anything about the hash. What's the recommended solution in that case?

For example:

<script type="text/javascript" src="${requestScope.staticContentPath}/dist/webpack.common.js" data-order="1" data-relative="/dist/webpack.common.js" onerror="onScriptError(event)" onload="onScriptLoad(event)"></script>
<script type="text/javascript" src="${requestScope.staticContentPath}/dist/home.entry.js" data-order="2" data-relative="/dist/home.entry.js" onerror="onScriptError(event)" onload="onScriptLoad(event)"></script>

In that instance, I don't want the webpack.common.js to have the hash as the Java server doesn't know what it is and already contains its own cache busting mechanism.

[charrondev]

What is the actual technical reason blocking this? I've seen it referenced a few times. We don't necessarily need our chunknames to need to be a function, but having the path capable of being a function would work fine.

The use case:

We have multiple repos being joined together at build time and are generating 1 common chunk, and 1 library chunk using splitChunks.

For the moment these files need to be stored in their respective repos because these outputted files are version controlled (we are trying to move away from this though). Even after doing that though, we'd like the files to be put in their respective repo folders so that the application can add preload tags for them. To do that it needs to know they are in a predictable location based on the addon belong to.

Right now this is being worked around by adding the requisite file paths into the name and chunkname of each entry. This automated for the initial entries, which I crawl and generate long names with filepaths in them, but the chunknames require them to be manually typed. This works for now but is not feasible long term.

Eg.

if (richEditor) {
    const mountEditor = await import(/* webpackChunkName: "plugins/rich-editor/js/webpack/chunks/mountEditor" */ "@rich-editor/mountEditor");
    mountEditor.default(richEditor);
}

I'd like to be able to use a function either for the path or the chunkName so we don't need to add bits like plugins/rich-editor/js/webpack/chunks to the chunkname comment.

[ghetolay]

I'll add my use case where we want to protect some code behind authentication inside an SPA. So we need to move some lazy loaded chunk into a protected folder (based on modules it contains) and keep the rest public.

Current workaround is using a plugin to edit chunk name like above to include full path and using chunkFilename: [name].js.

[philostler]

Had anyone discovered a workaround for this issue? I've just bumped into the same problem.

[alecklandgraf]

I would like to see this too. My use case is when the chunkFilename becomes very long, longer than 128 characters, I cannot upload the sourcemaps to our error reporting service.
I'm working to lift that constraint, but something like this would be great.

// if slicing on name was supported
config.output.chunkFilename = 'assets/[name:10].[contenthash].chunk.js';

// or

config.output.chunkFilename = (chunkData) => {
  if (chunkData.chunk.name.length > 120) {
    return `assets/${truncate(chunkData.chunk.name)}.[contenthash].chunk.js`
  }

  return 'assets/[name].[contenthash].chunk.js';
};

[ArthurYidi]

@philostler @alecklandgraf https://webpack.js.org/plugins/source-map-dev-tool-plugin/ can be a great workaround

[alecklandgraf]

@ArthurYidi thanks for pointing me to that! I was missing config.output.sourceMapFilename, I can just update this.

// attempt to get our sourcemap filenames under 128 characters
config.output.sourceMapFilename = 'assets/sourcemaps/[contenthash].js.map';

[crazyx13th]

at the moment I use https://www.npmjs.com/package/chunk-rename-webpack-plugin as a workaround.
but if config.output.filename can be a function, config.output.chunkFilename should be handled equal.

thx!

grettings
crazyx13th

[mahaina]

at the moment I use https://www.npmjs.com/package/chunk-rename-webpack-plugin as a workaround.
but if config.output.filename can be a function, config.output.chunkFilename should be handled equal.

thx!

grettings
crazyx13th

also need function chunkFilename to give conditional chunkFilename

[mahaina]

at the moment I use https://www.npmjs.com/package/chunk-rename-webpack-plugin as a workaround.
but if config.output.filename can be a function, config.output.chunkFilename should be handled equal.

thx!

grettings
crazyx13th

I used this plugin but got an bootstrap:811 Uncaught ChunkLoadError: Loading chunk [mymodulename] failed. error

I'm using webpack 4. Is that the problem?
thx!

[crazyx13th]

I using webpack 4 too, mhh...

[vaxul]

@mahaina
For Webpack 4 I would recommend https://www.npmjs.com/package/enhanced-webpack-chunk-rename-plugin as workaround.

[alexander-akait]

Let's close in favor https://github.com/webpack/webpack/pull/11530, after merge we will open new issue