Update dependency webpack to v5.107.2#1070
Conversation
Claudia-Anthropica
left a comment
There was a problem hiding this comment.
@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.
| "typescript-plugin-css-modules": "5.2.0", | ||
| "vitest": "4.1.7", | ||
| "webpack": "5.107.0", | ||
| "webpack": "5.107.1", |
There was a problem hiding this comment.
[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.
There was a problem hiding this comment.
@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.
There was a problem hiding this comment.
@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.
There was a problem hiding this comment.
@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.)
There was a problem hiding this comment.
@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.
There was a problem hiding this comment.
@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.
There was a problem hiding this comment.
@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
left a comment
There was a problem hiding this comment.
@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
left a comment
There was a problem hiding this comment.
@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.
4c151f2 to
9795711
Compare
Claudia-Anthropica
left a comment
There was a problem hiding this comment.
@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.
9795711 to
46476fe
Compare
Claudia-Anthropica
left a comment
There was a problem hiding this comment.
@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.
46476fe to
203b78f
Compare
Claudia-Anthropica
left a comment
There was a problem hiding this comment.
@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.
203b78f to
1572a69
Compare
Claudia-Anthropica
left a comment
There was a problem hiding this comment.
@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.
Renovate Ignore NotificationBecause you closed this PR without merging, Renovate will ignore this update ( If you accidentally closed this PR, or if you changed your mind: rename this PR to get a fresh replacement PR. |
This PR contains the following updates:
5.107.0→5.107.2Release Notes
webpack/webpack (webpack)
v5.107.2Compare Source
Patch Changes
Reduce per-file overhead in
ContextModuleFactory.resolveDependenciesby batchingalternativeRequestshook 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 inRequireContextPlugin) 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-filerequire.contextdrops a further ~15 ms (after the watch-mode purge fix in the same release). (by @alexander-akait in #21020)Include each external info's
runtimeConditioninConcatenatedModule#updateHashso 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#getSideEffectsConnectionStatewalk 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
ReferenceErroron the first activation of a lazy-compiled module whenoutput.library.typeproduces 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. WhenlazyCompilationactivates 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
LazyCompilationProxyModulenow declares statically-enumerable externals (string and object forms ofexternals) 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
entryOptionswhen an async block joins an existing entrypoint. (by @alexander-akait in #21026)Release per-child
codeGenerationResultsinMultiCompilerand atCompiler.closeto reduce memory retention. (by @alexander-akait in #21015)Reduce peak memory of
SourceMapDevToolPluginon large builds (closes #20961). (by @alexander-akait in #20963)Fix slow
require.context()/ dynamicimport()rebuilds in watch mode (#13636). When a file inside a watched context directory changed,NodeWatchFileSystemwould callinputFileSystem.purge(contextDir). The enhanced-resolvepurgeimplementation matches cache keys withkey.startsWith(contextDir), so the stat cache of every file under the directory was discarded on every rebuild —ContextModuleFactory.resolveDependenciesthen 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,purgeis now called with{ exact: true }(added inenhanced-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 parentreaddiras before. (by @alexander-akait in #21020)v5.107.1Compare 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
parseErrorcallback ("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 sodecodeHtmlEntitieshandles all named entities (including legacy bare forms like&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 ofNAMEare read. Previously webpack treated every export of such modules as referenced (because the barerequire()dependency reportsEXPORTS_OBJECT_REFERENCED), so unusedexports.x = ...assignments remained in the bundle even withusedExportsenabled. The parser now forwardsNAME.x/NAME.x()/NAME["x"]accesses to the underlyingCommonJsRequireDependencyas referenced exports, falling back to the full exports object the momentNAMEis 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 exceededthrown fromHarmonyImportSideEffectDependency.getModuleEvaluationSideEffectsStateon long linear chains of side-effect-free imports.NormalModule.getSideEffectsConnectionStatepreviously descended throughHarmonyImportSideEffectDependency.getModuleEvaluationSideEffectsStaterecursively, 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
NormalModuleFactoryparser/generator types: (by @alexander-akait in #20999)module.generator.htmlnow usesHtmlGeneratorOptionsinstead ofEmptyGeneratorOptions(theextractoption was hidden from thecreateGenerator/generatorhook types).webassembly/async,webassembly/sync) generator hooks now useEmptyGeneratorOptionsinstead ofEmptyParserOptions.NormalModuleFactory#getParser/createParser/getGenerator/createGeneratorare now generic over the module-type string, returning the specific parser/generator class for known types (e.g.JavascriptParserfor"javascript/auto",CssGeneratorfor"css", etc.) instead of always returning the baseParser/Generator.NormalModuleCreateDatais now generic over the module type soparser,parserOptions,generator, andgeneratorOptionsare narrowed to the specific class / options for the giventype.Link import bindings used inside
define(...)callbacks in ES modules. Previously,HarmonyDetectionParserPluginskipped walking the arguments ofdefinecalls in harmony modules, so references to imported bindings inside an inline AMDdefinefactory (e.g.define(function () { console.log(foo); })) were not rewritten to their imported references and could causeReferenceErrorat runtime. Inner graph usage analysis is also fixed for the related patternconst 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.cssfile was emitted to disk but never referenced from the extracted HTML (no<link>tag), and whensplitChunksextracted 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 inhtml-webpack-plugin#1838andwebpack/mini-css-extract-plugin#959for HTML-entry builds.nonce/crossorigin/referrerpolicyare copied from the originating tag onto the emitted<link>. (by @alexander-akait in #21002)Allow
devtoolandSourceMapDevToolPlugin(or multipleSourceMapDevToolPlugininstances) to coexist on the same asset. Previously the second instance would silently skip any asset whoseinfo.related.sourceMaphad already been set by an earlier instance, and even when it ran the asset had been rewrapped as aRawSourceso no source map could be recovered — producing an empty.mapfile. 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 additionalrelated.sourceMapentries instead of overwriting them. The classic workaround of pairingdevtool: 'hidden-source-map'with anew webpack.SourceMapDevToolPlugin({ filename: '[file].secondary.map', noSources: true })now produces both maps in a single build. (by @alexander-akait in #21001)Narrow
TemplatePathFncallback types by context.pathData.chunkis now non-optional for chunk filename callbacks (output.filename,chunkFilename,cssFilename,cssChunkFilename,htmlFilename,htmlChunkFilename,optimization.splitChunks.cacheGroups[*].filename), andpathData.moduleis non-optional for module filename callbacks (output.assetModuleFilename, per-modulegenerator.filename/generator.outputPath,module.parser.css.localIdentName). (by @alexander-akait in #20987)Tighten the
CreateDatatypedef inNormalModuleFactory.CreateDatanow represents the fully-populated value passed to thecreateModule,module, andcreateModuleClasshooks (NormalModuleCreateData & { settings: ModuleSettings }), whileResolveData.createDatais typed asPartial<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/webpackPreloadmagic comments from leaking acrossimport()call sites that share awebpackChunkName. When two imports targeted the same named chunk and only one of them setwebpackPrefetch: true, the prefetch directive was applied from every parent chunk that referenced the named chunk. Prefetch and preload orders are now resolved perimport()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) inoutput.publicPathnot being interpolated at runtime. The detection regex inRuntimePluginonly matched[fullhash]/[hash]without a length suffix, so thePublicPathRuntimeModulewas not flagged as a full-hash module and__webpack_require__.pwas emitted with the placeholderXXXXleft in place (e.g.out/XXXX/) instead of the real hash truncated to the requested length. (by @alexander-akait in #21004)Re-export
ModuleNotFoundErrorfromwebpack/lib/ModuleNotFoundErrorfor 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)
🚦 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.
This PR was generated by Mend Renovate. View the repository job log.