🦋 Changeset detected

Latest commit: 0f6670e

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 (7639066).

Install it locally:

• npm

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

• yarn

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

• pnpm

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

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 92.47%. Comparing base (3cb8578) to head (0f6670e).
⚠️ Report is 9 commits behind head on main.

@@            Coverage Diff             @@
##             main   #21326      +/-   ##
==========================================
- Coverage   92.86%   92.47%   -0.40%     
==========================================
  Files         594      594              
  Lines       65210    65335     +125     
  Branches    18143    18189      +46     
==========================================
- Hits        60559    60417     -142     
- Misses       4651     4918     +267     

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

Merging this PR will improve performance by 40.13%

⚡ 2 improved benchmarks
❌ 2 regressed benchmarks
✅ 140 untouched benchmarks

Performance Changes

_{Comparing fix-lazy-barrel-flag-dep (0f6670e) with main (c2628cf)}

@hai-x looks good let’s merge and make the patch release

@alexander-akait

Thanks for the review! I've reworked the approach in two ways:

• No more buildInfo state. The still-lazy re-export request keys are now derived from LazyBarrelController's per-compilation state (getLazyRequestKeys), so no need to store it on the module.
• Fixed a related staleness under experiments.cacheUnaffected. The module mem cache restores provided exports before the disk cache check. The reference snapshot now records a connection count, so added/removed connections invalidate the mem cache.

Could you take another look?

tried with the current patch and seems this doesn't fix the issue.

i delete webpack cache and start a fresh build, few lazy compilations later it throws

Webpack cache efficiency: 0% (0/113)
Webpack cache efficiency: 3% (112/3948)
Webpack cache efficiency: 97% (3948/4062)
export 'useLocalObservable' (imported as 'useLocalObservable') was not found in 'mobx-react' (possible exports: MobXProviderContext, PropTypes, Provider, disposeOnUnmount, inject, observer)
export 'useLocalObservable' (imported as 'useLocalObservable') was not found in 'mobx-react' (possible exports: MobXProviderContext, PropTypes, Provider, disposeOnUnmount, inject, observer)
export 'useLocalObservable' (imported as 'useLocalObservable') was not found in 'mobx-react' (possible exports: MobXProviderContext, PropTypes, Provider, disposeOnUnmount, inject, observer)

now that i can reproduce the issue consistently locally, this PR behaves the same as 5.108.3, while #21322 prevents the errors.

though i applied only this PR on top of 5.108.3, in case this depends on something else merged after 5.108.3...

though i applied only this PR on top of 5.108.3, in case this depends on something else merged after 5.108.3...

@Knagis Hi, have you try the version, or just edit the webpack code in the node_modules?

@Knagis can you try to remove the old cache and run code with this patch

The PR which I closed just disable cache, yes it is the fix, but the solution is not good, ideally we should find the root of the problem and keep cache

@Knagis Could you share some reproduction steps? I can repro it with filesystem cache by following steps:

1. Clean the disk cache.
2. Write index.js and then build it.

import { PropTypes } from "mobx-react";

console.log(PropTypes);

3. Update index.js and then build it.

import { useLocalObservable } from "mobx-react";

console.log(useLocalObservable);

i'm taking https://patch-diff.githubusercontent.com/raw/webpack/webpack/pull/21326.patch and adding it as yarn patch on top of 5.108.3 (we have all kinds of rules in place that force npm packages from our own repository etc. so patch is the easiest)

in my scenario it now fails with just memory cache, not even restarting the build (initial build, then one lazy chunk builds and then the next one fails).

in my scenario it now fails with just memory cache, not even restarting the build (initial build, then one lazy chunk builds and then the next one fails).

Make sense, let me try it with memory cache and lazy compilation. Thanks for sharing.

@Knagis Yeah, this issue is about unsafe memory cache with cacheUnaffected. Could you try the latest patch? Thanks.

Types Coverage

@Knagis friendly ping, want to make the patch release

Right now with the latest version of this PR i can no longer reproduce the error. Not that i could reproduce all the cases before :)

@Knagis lets try, if you faced with the issue agin after the patch release feel free to open a new issue