Skip to content

Update dependency webpack to v5.107.2#1070

Closed
renovate[bot] wants to merge 1 commit into
developfrom
renovate/webpack-5.x
Closed

Update dependency webpack to v5.107.2#1070
renovate[bot] wants to merge 1 commit into
developfrom
renovate/webpack-5.x

Conversation

@renovate

@renovate renovate Bot commented May 21, 2026

Copy link
Copy Markdown
Contributor

This PR contains the following updates:

Package Change Age Confidence
webpack 5.107.05.107.2 age confidence

Release Notes

webpack/webpack (webpack)

v5.107.2

Compare Source

Patch Changes
  • Reduce per-file overhead in ContextModuleFactory.resolveDependencies by batching alternativeRequests hook calls. Previously the hook was invoked once per file in the context (with a single-item array), paying per-call overhead (closure allocation, resolverFactory.get, intermediate arrays in RequireContextPlugin) for every file. The hook is now invoked once per directory with all matched files in one batch — RequireContextPlugin's tap already iterates the items array, so the output is unchanged. Steady-state rebuild on a 4000-file require.context drops a further ~15 ms (after the watch-mode purge fix in the same release). (by @​alexander-akait in #​21020)

  • Include each external info's runtimeCondition in ConcatenatedModule#updateHash so changes to a concatenated external's runtime condition invalidate persistent caches instead of slipping through with the module id alone. (by @​alexander-akait in #​21023)

  • Fix HTML [contenthash] for referenced asset and inline-style URL changes. (by @​alexander-akait in #​21018)

  • Resolve chunk-hash placeholders in chunk URLs embedded into extracted HTML. (by @​alexander-akait in #​21018)

  • Remove unnecessary __webpack_require__ runtime helpers in ESM library output with multi-module chunks. (by @​xiaoxiaojx in #​21032)

  • Rewrite NormalModule#getSideEffectsConnectionState walk as an allocation-light iterative loop instead of a generator trampoline, restoring rebuild performance lost in #​20993 while keeping deep import chains stack-safe. (by @​alexander-akait in #​21014)

  • Fix runtime ReferenceError on the first activation of a lazy-compiled module when output.library.type produces a closure-wrapped bundle (umd, umd2, amd, amd-require, system). (by @​alexander-akait in #​21013)

    External modules of these types reference closure-bound identifiers like __WEBPACK_EXTERNAL_MODULE_react__, supplied by the library wrapper that is generated once per chunk. When lazyCompilation activates an entry or import for the first time, any external dependency the lazily-built module pulls in arrives in a hot-update chunk that lives outside the original wrapper closure, so its factory body cannot resolve the closure identifier and only a manual page refresh recovers.

    The inactive LazyCompilationProxyModule now declares statically-enumerable externals (string and object forms of externals) as its own dependencies, so the initial entry chunk's library wrapper already exposes their closure identifiers. When activation later pulls in those externals through the lazily-compiled module, they resolve to the already-installed factories instead of throwing. Function and RegExp externals are not pre-populated because their effective request set isn't knowable up front.

  • Fill in missing entryOptions when an async block joins an existing entrypoint. (by @​alexander-akait in #​21026)

  • Release per-child codeGenerationResults in MultiCompiler and at Compiler.close to reduce memory retention. (by @​alexander-akait in #​21015)

  • Reduce peak memory of SourceMapDevToolPlugin on large builds (closes #​20961). (by @​alexander-akait in #​20963)

  • Fix slow require.context() / dynamic import() rebuilds in watch mode (#​13636). When a file inside a watched context directory changed, NodeWatchFileSystem would call inputFileSystem.purge(contextDir). The enhanced-resolve purge implementation matches cache keys with key.startsWith(contextDir), so the stat cache of every file under the directory was discarded on every rebuild — ContextModuleFactory.resolveDependencies then re-stat-ed the whole tree on each rebuild. Single-file rebuilds on a 4000-file context now reuse the warm stat cache, dropping median rebuild from ~1260 ms to ~650 ms in a local reproduction (≈49%). For directory items that are explicitly watched contexts, purge is now called with { exact: true } (added in enhanced-resolve@5.22.0) so only the directory's own entry is invalidated; file-level changes in the same aggregated event continue to purge file stats and the parent readdir as before. (by @​alexander-akait in #​21020)

v5.107.1

Compare Source

Patch Changes
  • Align the experimental HTML tokenizer with the WHATWG spec: fix offset-range bugs in the script-data, content-mode end-tag, attribute-value, and EOF states; surface tokenizer parse errors to consumers via a new parseError callback ("warning" when the tokenizer recovers and the emitted token is still well-formed, "error" when the offset range is incomplete — e.g. eof-in-tag); and add the full WHATWG named character references table so decodeHtmlEntities handles all named entities (including legacy bare forms like &AMP and multi-code-point entities like ≂̸) with proper longest-prefix backtracking. (by @​alexander-akait in #​21000)

  • Tree-shake CommonJS modules imported through a const NAME = require(LITERAL) binding when only static members of NAME are read. Previously webpack treated every export of such modules as referenced (because the bare require() dependency reports EXPORTS_OBJECT_REFERENCED), so unused exports.x = ... assignments remained in the bundle even with usedExports enabled. The parser now forwards NAME.x / NAME.x() / NAME["x"] accesses to the underlying CommonJsRequireDependency as referenced exports, falling back to the full exports object the moment NAME is read in any other context (passed by value, destructured later, accessed with a dynamic key, …). This brings the binding form to parity with the existing destructuring form (const { x } = require(...)). (by @​alexander-akait in #​21003)

  • Fix RangeError: Maximum call stack size exceeded thrown from HarmonyImportSideEffectDependency.getModuleEvaluationSideEffectsState on long linear chains of side-effect-free imports. NormalModule.getSideEffectsConnectionState previously descended through HarmonyImportSideEffectDependency.getModuleEvaluationSideEffectsState recursively, adding two stack frames per module, which overflowed V8's stack at a few thousand modules deep. The traversal is now iterative. (by @​alexander-akait in #​20993)

  • Fix NormalModuleFactory parser/generator types: (by @​alexander-akait in #​20999)

    • module.generator.html now uses HtmlGeneratorOptions instead of EmptyGeneratorOptions (the extract option was hidden from the createGenerator / generator hook types).
    • WebAssembly (webassembly/async, webassembly/sync) generator hooks now use EmptyGeneratorOptions instead of EmptyParserOptions.
    • NormalModuleFactory#getParser / createParser / getGenerator / createGenerator are now generic over the module-type string, returning the specific parser/generator class for known types (e.g. JavascriptParser for "javascript/auto", CssGenerator for "css", etc.) instead of always returning the base Parser / Generator.
    • NormalModuleCreateData is now generic over the module type so parser, parserOptions, generator, and generatorOptions are narrowed to the specific class / options for the given type.
  • Link import bindings used inside define(...) callbacks in ES modules. Previously, HarmonyDetectionParserPlugin skipped walking the arguments of define calls in harmony modules, so references to imported bindings inside an inline AMD define factory (e.g. define(function () { console.log(foo); })) were not rewritten to their imported references and could cause ReferenceError at runtime. Inner graph usage analysis is also fixed for the related pattern const fn = function () { foo; }; define(fn);. (by @​alexander-akait in #​20990)

  • HTML-entry pipeline (experiments.html + experiments.css): emit <link rel="stylesheet"> tags for CSS chunks reachable from a <script src> entry. Previously when the bundled JS imported CSS, the resulting .css file was emitted to disk but never referenced from the extracted HTML (no <link> tag), and when splitChunks extracted CSS into sibling chunks the HTML cloned the originating <script> for each one — producing <script src="style.js"> pointing at non-existent JS filenames instead of <link rel="stylesheet" href="style.css">. CSS chunks are now sorted by the entrypoint's module post-order index so the <link> tags also appear in source import order, fixing the cascade ordering issue documented in html-webpack-plugin#1838 and webpack/mini-css-extract-plugin#959 for HTML-entry builds. nonce/crossorigin/referrerpolicy are copied from the originating tag onto the emitted <link>. (by @​alexander-akait in #​21002)

  • Allow devtool and SourceMapDevToolPlugin (or multiple SourceMapDevToolPlugin instances) to coexist on the same asset. Previously the second instance would silently skip any asset whose info.related.sourceMap had already been set by an earlier instance, and even when it ran the asset had been rewrapped as a RawSource so no source map could be recovered — producing an empty .map file. The plugin now keeps a per-compilation stash of pristine source maps, namespaces its persistent cache entries by the options that affect output, and appends additional related.sourceMap entries instead of overwriting them. The classic workaround of pairing devtool: 'hidden-source-map' with a new webpack.SourceMapDevToolPlugin({ filename: '[file].secondary.map', noSources: true }) now produces both maps in a single build. (by @​alexander-akait in #​21001)

  • Narrow TemplatePathFn callback types by context. pathData.chunk is now non-optional for chunk filename callbacks (output.filename, chunkFilename, cssFilename, cssChunkFilename, htmlFilename, htmlChunkFilename, optimization.splitChunks.cacheGroups[*].filename), and pathData.module is non-optional for module filename callbacks (output.assetModuleFilename, per-module generator.filename / generator.outputPath, module.parser.css.localIdentName). (by @​alexander-akait in #​20987)

  • Tighten the CreateData typedef in NormalModuleFactory. CreateData now represents the fully-populated value passed to the createModule, module, and createModuleClass hooks (NormalModuleCreateData & { settings: ModuleSettings }), while ResolveData.createData is typed as Partial<CreateData> to reflect the empty initial state. Plugins tapping those hooks no longer need to cast individual fields away from optional. (by @​alexander-akait in #​20992)

  • Stop webpackPrefetch / webpackPreload magic comments from leaking across import() call sites that share a webpackChunkName. When two imports targeted the same named chunk and only one of them set webpackPrefetch: true, the prefetch directive was applied from every parent chunk that referenced the named chunk. Prefetch and preload orders are now resolved per import() call site instead of from the shared chunk group's accumulated options. (by @​alexander-akait in #​20994)

  • Fix [fullhash:N] and [hash:N] (with length suffix) in output.publicPath not being interpolated at runtime. The detection regex in RuntimePlugin only matched [fullhash] / [hash] without a length suffix, so the PublicPathRuntimeModule was not flagged as a full-hash module and __webpack_require__.p was emitted with the placeholder XXXX left in place (e.g. out/XXXX/) instead of the real hash truncated to the requested length. (by @​alexander-akait in #​21004)

  • Re-export ModuleNotFoundError from webpack/lib/ModuleNotFoundError for backward compatibility with old plugins that import it from that path. This re-export will be removed in webpack 6. (by @​alexander-akait in #​20988)


Configuration

📅 Schedule: (UTC)

  • Branch creation
    • At any time (no schedule defined)
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@Claudia-Anthropica Claudia-Anthropica left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@renovate Straightforward webpack 5.107.0 → 5.107.1 patch bump — release notes are all upstream bug/type fixes and the lockfile diff is just the version propagating through peer contexts, nothing concerning. The only blocker is CI: the run-tests / build check fails because the cached client SBOM is now stale relative to the changed lockfile. Regenerate it and this is good to merge.

Comment thread client/package.json Outdated
"typescript-plugin-css-modules": "5.2.0",
"vitest": "4.1.7",
"webpack": "5.107.0",
"webpack": "5.107.1",

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[high] This bump changes package.json and pnpm-lock.yaml, but the cached client SBOM under client/sbom/ wasn't regenerated, so run-tests / build fails with client/sbom/ is stale (pnpm-lock.yaml or package.json changed). The check recomputes a shasum over pnpm-lock.yaml + package.json and compares it to sbom/.lock-hash, which no longer matches. Run pnpm run sbom:force in client/ and commit the updated sbom/bom.json and sbom/.lock-hash.

🤖 Prompt for AI agents

In the client/ directory, the cached CycloneDX SBOM is stale after the webpack version bump, failing the run-tests / build CI check. Run pnpm run sbom:force from client/ and commit the regenerated client/sbom/bom.json and client/sbom/.lock-hash.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@krusche Still stale, unfortunately. cat pnpm-lock.yaml package.json | shasum -a 256 in client/ gives e202f70d… but sbom/.lock-hash is still a942f278…, so run-tests / build will fail the client-SBOM check as soon as it gets past install. Merging develop pulled in the auto-refresh workflow from #1073, but its run on the merge commit failed before executing any jobs, so the SBOM never got regenerated. Quickest unblock is to run pnpm run sbom:force in client/ and commit sbom/bom.json + sbom/.lock-hash. Leaving this open.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@krusche Thanks for the develop merge + refresh_sbom tweak, but it still didn't unblock. The refresh-sbom run on this commit (26278787482) failed at the workflow-file level with zero jobs executed, so the SBOM never got regenerated — sbom/.lock-hash is still a942f278… while cat pnpm-lock.yaml package.json | shasum -a 256 in client/ wants e202f70d…. Separately, install itself is currently dying on pnpm's minimum-release-age policy for webpack@5.107.1 (published 2026-05-21 14:29 UTC); that clears once it's >24h old (after ~14:29 UTC today), so a CI re-run later will get past install. But the SBOM still needs a manual pnpm run sbom:force + commit of sbom/bom.json and sbom/.lock-hash — the auto workflow won't do it. Leaving this open.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@krusche Quick update after the rebase: the client SBOM is still stale — sbom/.lock-hash is bf47dc04… but cat pnpm-lock.yaml package.json | shasum -a 256 in client/ now wants d8785cb6…, and the refresh auto-refresh job failed again, so it's still on a manual pnpm run sbom:force + commit of sbom/bom.json and sbom/.lock-hash. Good news though: the pnpm minimum-release-age block on webpack@5.107.1 has cleared, so Install client dependencies passes now and the stale SBOM is the only thing keeping run-tests / build red. (The build-server red is an unrelated git-checkout/auth flake — exit 128 — just needs a re-run.)

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@krusche Still open after the 5.107.2 re-bump. The client SBOM hash is stale again: cat pnpm-lock.yaml package.json | shasum -a 256 in client/ now gives 97f060e8…, but client/sbom/.lock-hash is still bf47dc04…, and the refresh workflow cannot fix it because the SBOM bot credentials are not configured. CI is also currently stopped earlier by pnpm's minimum-release-age check for webpack@5.107.2 (published 2026-05-25 15:18 UTC), which should clear on a re-run after 2026-05-26 15:18 UTC. Leaving this unresolved until pnpm run sbom:force is committed and CI is green.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@renovate[bot] Still open on this SHA. run-tests / build reaches the client SBOM freshness check and fails with client/sbom/ is stale; locally the committed client/sbom/.lock-hash is bf47dc04… while cat pnpm-lock.yaml package.json | shasum -a 256 now wants 944cbab1…. build-client is green now, so the release-age gate is no longer a blocker, but the SBOM still needs pnpm run sbom:force in client/ and the updated client/sbom/ files committed.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@renovate[bot] Still open on the current SHA. client/sbom/.lock-hash is still bf47dc04…, but the current cat pnpm-lock.yaml package.json | shasum -a 256 value is 61edbee7…, and run-tests / build is failing on the same client/sbom/ is stale check. The refresh job also fails because the SBOM bot credentials are not configured, so this still needs a manual pnpm run sbom:force in client/ plus the updated client/sbom/ files committed.

@Claudia-Anthropica Claudia-Anthropica left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@krusche Two things keeping CI red. First, the client SBOM is still stale — merging develop pulled in the auto-refresh workflow from #1073, but its run on the merge commit failed without executing any jobs, so it never regenerated; details in the thread on package.json. Second, both build-dev-container / build-client and run-tests / build now die at pnpm install because pnpm 11.2.2 (pulled in via the develop merge) rejects webpack@5.107.1 under its minimum-release-age policy — it was published 2026-05-21 14:29 UTC, inside the ~1-day cutoff. That one's transient and clears once the package is >24h old, so a CI re-run after ~14:29 UTC today should pass it. The bump itself is fine; requesting changes until the SBOM is committed and CI is green.

@Claudia-Anthropica Claudia-Anthropica left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@krusche Still blocked. The client SBOM is unchanged from before (stored hash a942f278… vs the e202f70d… the build expects), and the auto-refresh workflow failed again on this commit, so it needs a manual pnpm run sbom:force + commit — details in the package.json thread. The other CI failures are pnpm's transient minimum-release-age check on webpack@5.107.1, which clears on a re-run once it's >24h old. The bump itself is fine.

@renovate renovate Bot force-pushed the renovate/webpack-5.x branch 2 times, most recently from 4c151f2 to 9795711 Compare May 23, 2026 14:36

@Claudia-Anthropica Claudia-Anthropica left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@krusche Still just the stale client SBOM blocking this. run-tests / build now gets all the way through pnpm install and dies only on the "Verify client SBOM is up-to-date" step — the pnpm minimum-release-age block on webpack@5.107.1 has cleared, so install is green again. Fix is the usual pnpm run sbom:force in client/ + commit sbom/bom.json and sbom/.lock-hash (the refresh auto-bot failed again and won't do it). The build-server red is an unrelated git-checkout flake (exit 128) and needs a re-run, not a code change. The bump itself is fine.

@renovate renovate Bot changed the title Update dependency webpack to v5.107.1 Update dependency webpack to v5.107.2 May 25, 2026
@renovate renovate Bot force-pushed the renovate/webpack-5.x branch from 9795711 to 46476fe Compare May 25, 2026 17:32

@Claudia-Anthropica Claudia-Anthropica left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@renovate The webpack bump itself still looks fine, but CI is red for PR-related client blockers: pnpm's release-age gate for webpack 5.107.2 and the stale client SBOM. The release-age gate should clear after 2026-05-26 15:18 UTC, but the SBOM still needs a manual pnpm run sbom:force and committed client/sbom/ updates before this can go green.

@renovate renovate Bot force-pushed the renovate/webpack-5.x branch from 46476fe to 203b78f Compare June 1, 2026 19:17

@Claudia-Anthropica Claudia-Anthropica left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@renovate[bot] The webpack 5.107.2 bump itself still looks fine, and the release-age install failure is gone. run-tests / build is still red because client/sbom/ is stale against the changed package.json and lockfile, so I'm keeping this as changes requested until the SBOM is regenerated and committed.

@renovate renovate Bot force-pushed the renovate/webpack-5.x branch from 203b78f to 1572a69 Compare June 13, 2026 15:58

@Claudia-Anthropica Claudia-Anthropica left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@renovate[bot] The webpack bump itself still looks fine, but run-tests / build is still red because client/sbom/ is stale against the updated package.json and lockfile. The auto refresh job also fails because the SBOM bot credentials are not configured, so this still needs a manual pnpm run sbom:force in client/ and committed client/sbom/ updates.

@krusche

krusche commented Jun 16, 2026

Copy link
Copy Markdown
Member

Superseded by #1101, which consolidates the client and server dependency updates into a single PR (this dependency is included there at webpack 5.107.2). Closing in favor of #1101.

@krusche krusche closed this Jun 16, 2026
@renovate

renovate Bot commented Jun 16, 2026

Copy link
Copy Markdown
Contributor Author

Renovate Ignore Notification

Because you closed this PR without merging, Renovate will ignore this update (5.107.2). You will get a PR once a newer version is released. To ignore this dependency forever, add it to the ignoreDeps array of your Renovate config.

If you accidentally closed this PR, or if you changed your mind: rename this PR to get a fresh replacement PR.

@renovate renovate Bot deleted the renovate/webpack-5.x branch June 16, 2026 13:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants