Prevent chunk files from escaping output.path when chunk names contain path separators

[nathanielmiller23]

Have you used AI?

None

Feature Proposal

Please harden chunk name handling so path separator components in webpackChunkName cannot cause emitted chunk files to resolve outside output.path.

A value like "../../outside/chunk" should either emit a warning and fall back to
a numeric chunk ID, or have the path components stripped silently. As currently implemented, webpackChunkName values appear to flow into emitted chunk paths without containment enforcement.

Three locations could each independently implement this:

1. lib/dependencies/ImportParserPlugin.js (~line 337): validate
   webpackChunkName before storing it on the chunk object. Reject values
   containing /, \, or .. and emit a warning, falling back to a numeric ID.
   This is the earliest and most visible fix point.

2. lib/TemplatedPathPlugin.js (lines 262 and 285): apply path.basename()
   to the [name] replacement value before substitution, stripping any directory
   components regardless of how the chunk name was set.

3. lib/Compiler.js emitAssets function: after computing
   targetPath = join(outputFileSystem, outputPath, targetFile), assert that
   targetPath starts with outputPath before proceeding to mkdirp and
   writeFile. This defense-in-depth check would cover all asset emission paths,
   including the [path]/[pathname] cases in [path] in assetModuleFilename may unexpectedly traverse parent directories #11937 and asset/resource builds outside of dist when [pathname] contains references to hoisted node_modules #14392.

Option 1 gives the clearest developer-facing feedback. Option 3 is the broadest
fix and closes the same gap for asset module filenames at the same time.

Thank you! Keep up the great work

Feature Use Case

Feature Use Case

When a webpackChunkName magic comment contains ../ sequences, webpack writes
the generated chunk file to a path outside output.path with no warning or error.
This is surprising because output.path is documented as the target output
directory, and developers expect all emitted files to be contained within it.

Reproduction

src/app.js:

import(/* webpackChunkName: "../../outside/chunk" */ './module.js');

webpack.config.js:

const path = require('path');
module.exports = {
  mode: 'production',
  entry: './src/app.js',
  output: {
    path: path.resolve(__dirname, 'dist/a/b'),
    chunkFilename: '[name].js',
  },
};

After running npx webpack:

$ find dist -name "*.js" | sort
dist/a/b/main.js # expected -- inside output.path
dist/outside/chunk.js # unexpected -- escaped output.path via ../../

dist/outside/chunk.js is written two levels above the configured output.path
of dist/a/b. The directory is created automatically by webpack if it does not
exist.

Why this is surprising: path.posix.join('/project/dist/a/b', '../../outside/chunk.js')
resolves to /project/dist/outside/chunk.js. webpack performs this join at
Compiler.js:742 and proceeds to create parent directories and write the file
at the resolved path with no check that it remains within output.path.

Expected behavior: I think webpack should treat output.path as a strict containment boundary for emitted chunk assets.

This behavior also appears in #11937 ([path] in assetModuleFilename) and
#14392 ([pathname] with hoisted node_modules). A fix at the emitAssets
level would resolve all three cases in one place.

Additional Context

No response

[alexander-akait]

Changing output path using webpackChunkName is expected feature (special directory for CDN, writing manifest file for server side rendering, modify existing configurations), what your real problem? I feel like your issues was generated by AI, but you said No, is this issue was generated by AI?

lib/dependencies/ImportParserPlugin.js (~line 337)

No, you can't use numeric id because it contains something in comments, it will break long term cache

lib/TemplatedPathPlugin.js

Will break a lot of patterns

lib/Compiler.js emitAssets function: after computing
targetPath = join(outputFileSystem, outputPath, targetFile), assert that
targetPath starts with outputPath before proceeding to mkdirp and
writeFile

This is the only one place where we can improve it, but again - please show me your real problem to understand why it happens

[nathanielmiller23]

Thanks for the clarification and for taking the time to review this issue. I appreciate the detailed feedback and the discussion.