Incorrect cache invalidation using module with side effects and re-exporting from empty file

Bug report

Cache get invalidated on the second run when using a module with side effects (like console.log) and re-exporting from an empty file.

What is the current behavior? The cache pack gets invalid on the second run. On the third run and more cache hits.

If the current behavior is a bug, please provide the steps to reproduce.

https://github.com/7rulnik/webpack-repro-empty-export-cache-invalidation

There is side effect https://github.com/7rulnik/webpack-repro-empty-export-cache-invalidation/blob/main/convert/typescript/es.object.assign.js#L1 And there re-export from empty file https://github.com/7rulnik/webpack-repro-empty-export-cache-invalidation/blob/main/convert/typescript/index.js#L2

Run yarn webpack twice. You will find a log like this:

[webpack.cache.PackFileCacheStrategy] Pack got invalid because of write to:
ResolverCachePlugin|normal|dependencyType=|esm|path=|/Users/v7rulnik/projects/webpack-cache-test|request=|./index.js

What is the expected behavior?

A cache should not get invalidated on the second run.

Other relevant information:

You can come to the question «Why re-export from an empty file? Just delete it». Repro is based on the real case of Storybook. Storybook imports @storybook/addon-docs/dist/esm/frameworks/react/config.js.

Source code of addon-docs looks like this https://github.com/storybookjs/storybook/blob/6657698254b26df6aa7c4143eae8593bbfe5c208/addons/docs/src/lib/convert/typescript/index.ts. But types.ts contains only types https://github.com/storybookjs/storybook/blob/6657698254b26df6aa7c4143eae8593bbfe5c208/addons/docs/src/lib/convert/typescript/types.ts — this is why we get empty file. You can check published file https://unpkg.com/browse/@storybook/addon-docs@6.4.13/dist/esm/lib/convert/typescript/types.js And in this case, side effects come from core-js https://unpkg.com/browse/@storybook/addon-docs@6.4.13/dist/esm/lib/convert/typescript/convert.js. See https://unpkg.com/core-js@3.20.3/modules/es.array.map.js.

Also, the bug doesn’t reproduce when usedExports is set to false.

---

webpack version: 5.66.0 Node.js version: 14.17.6 Operating System: MacOS 12.0.1 (21A559) ARM

[markjm]

So on first run, cache is “invalidated” because of initial write to ResolverCachePlugin cache. This is actually expected because its the first time the pack is being created.

The second invalidation does look to be a bug due to exportsinfo hash including _usedName. I believe this should just be removed from the hash, as MangleExportsPlugin will run and fill this value anyway. The alternative would be to include the _usedName information in the pack as well (instead of just the hash), but the work to generate these usedNames given the exportsinfo seems pretty minimal

[sokra]

We don’t cache for any module where exports depend on other modules.

There is no theoretical limitation to that. We would need to snapshot and compare the dependencies for changes when doing that. And it gets a bit tricky with transitive dependencies.

Anyway to avoid that complexity we currently don’t do it.

But I don’t think that’s related to the problem…

---

I think the problem is that once we set the canMangle flag to false, they is no way to reset that. So we probably don’t want to set it in first place. I assume it’s caused by missing information about dependent modules in the first iteration of exports determiniation.