🦋 Changeset detected

Latest commit: 26efab0

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

This PR is packaged and the instant preview is available (26efab0).

Install it locally:

• npm

npm i -D webpack@https://pkg.pr.new/webpack@26efab0

• yarn

yarn add -D webpack@https://pkg.pr.new/webpack@26efab0

• pnpm

pnpm add -D webpack@https://pkg.pr.new/webpack@26efab0

Types Coverage

Codecov Report

❌ Patch coverage is 78.71222% with 162 lines in your changes missing coverage. Please review.
✅ Project coverage is 36.23%. Comparing base (46f1d0f) to head (26efab0).
⚠️ Report is 83 commits behind head on main.

❌ Your patch check has failed because the patch coverage (78.71%) is below the target coverage (90.00%). You can increase the patch coverage or adjust the target coverage.

❗ There is a different number of reports uploaded between BASE (46f1d0f) and HEAD (26efab0). Click for more details.

HEAD has 22 uploads less than BASE

Flag	BASE (46f1d0f)	HEAD (26efab0)
integration	20	0
test262	2	0

@@             Coverage Diff             @@
##             main   #20970       +/-   ##
===========================================
- Coverage   91.12%   36.23%   -54.90%     
===========================================
  Files         570      419      -151     
  Lines       57747    47616    -10131     
  Branches    15458    13049     -2409     
===========================================
- Hits        52622    17252    -35370     
- Misses       5125    30364    +25239     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Merging this PR will degrade performance by 50.31%

⚡ 3 improved benchmarks
❌ 9 regressed benchmarks
✅ 132 untouched benchmarks
⏩ 72 skipped benchmarks¹

Performance Changes

_{Comparing test-different-caching-system (26efab0) with main (3032402)}

It's hard to get a good benchmark until #20972 lands

Ran some local benchmarks comparing the old (ObjectMiddleware + BinaryMiddleware pipeline) vs new (Encoder/Decoder) serialization on representative webpack-like data (5000 modules, 15000 dependencies, realistic path lengths and repeated type strings).

Deserialization performance concern

                 Serialize    Deserialize    Size
Old pipeline      59.0 ms       29.6 ms     4198 KB
New Encoder       37.2 ms       31.2 ms     4351 KB

Serialization is ~1.6x faster — the middleware pipeline elimination clearly pays off. However, deserialization shows a slight regression in this test shape, and in other data shapes (more nested objects, Sets) the gap widened to ~1.5x slower for the new format. The whole point of persistent cache is to speed up subsequent builds — deserialization (cache restore) runs on every cold start, while serialization only runs when content changes. A regression on the read path directly undermines the primary purpose of the cache system.

The root cause is architectural: the old BinaryMiddleware batches consecutive same-type values (N nulls → 2 bytes via RLE, N booleans → bit-packed, N integers → single header + N values), which gives the CPU predictable linear reads. The new Encoder dispatches per-value via tag bytes, which introduces more branches per value decoded.

It would be great to see deserialization benchmarks on real-world projects (e.g. the webpack codebase itself, or a large app with thousands of modules) to quantify the actual impact on cold-start cache restore time.

The architectural simplification (4-layer middleware → single-pass Encoder/Decoder) and string deduplication are solid improvements — the deserialization path is the main thing worth investigating before this lands.

@avivkeller We can't ship it in webpack@5, it is a breaking change, also a lot of changes in one PR, I can't review and validate, for such changes we need discussion firstly, I don't know architecture and to be honestly from this logic we bring nothing expect a lot of breaking changes