Skip to content

[Bug]: Opting into shared tree shaking breaks existing build with prefix shared keys #14098

Description

@giavinh79

System Info

System:
OS: macOS 26.5
CPU: (10) arm64 Apple M1 Pro
Memory: 73.77 MB / 32.00 GB
Shell: 5.9 - /opt/homebrew/bin/zsh
Binaries:
Node: 22.21.1 - /Users/user/mise/installs/node/22.21.1/bin/node
npm: 10.9.4 - /Users/user/mise/installs/node/22.21.1/bin/npm
pnpm: 10.16.0 - /Users/user/mise/installs/node/22.21.1/bin/pnpm
bun: 1.3.13 - /Users/user/mise/installs/node/22.21.1/bin/bun
Browsers:
Chrome: 148.0.7778.178
Edge: 148.0.3967.70
Firefox: 150.0.3
Safari: 26.5
npmPackages:
@rspack/cli: 2.0.3 => 2.0.3
@rspack/core: 2.0.3 => 2.0.3

Details

Created small POC repo here with a lot of context in the repo README: https://github.com/giavinh79/mf-shared-tree-shaking-fallback-alias-libs-imports. It consists of two apps which import from a libs module marked as shared.

After opting an unrelated shared dependency (graphql) into shared tree shaking, an originally passing build fails with: "Collect deps Compile failed: × resolving fallback for shared module @demo/shared-lib/".

The failing shared key is a prefix key: @demo/shared-lib/. That prefix is intentional as in the normal shared config it lets us match nested imports such as @demo/shared-lib/index without enumerating every subpath (see more context in the repro readme). However, the same build passes if I did replace the prefix key with the exact import key @demo/shared-lib/index.

So the behavior I’m trying to understand is, currently the fallback treeshaking collection compiler seems to process every shared key currently - is this expected? Should prefix-style shared keys be avoided or is there a supported way to prevent these shared keys from being processed by the treeshaking compiler.

Thanks, and also happy to move this to module-federation/core if that’s the better place for this issue.

Reproduce link

https://github.com/giavinh79/mf-shared-tree-shaking-fallback-alias-libs-imports

Reproduce Steps

  1. pnpm build:shared passes
  2. pnpm build:tree-shaking fails with the following error:
Start building shared fallback resources ...
<w> [Module Federation Manifest Plugin] [ Module Federation Manifest Plugin ] Manifest will use absolute path resolution via its host at runtime, reason: publicPath='auto'
Collect deps Compile failed:   × resolving fallback for shared module @demo/shared-lib/

[rspack-cli] Error: Collect deps Compile failed

Metadata

Metadata

Assignees

No one assigned

    Labels

    pending triageThe issue/PR is currently untouched.

    Type

    Fields

    No fields configured for Bug.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions