Bug description

When using ProvideSharedPlugin (via SharePlugin) with packages that use the secondary entry point pattern (e.g. @mui/material/styles, @emotion/react/jsx-runtime, @apollo/client/link/http), rspack emits:

No version specified and unable to automatically determine one.
No version in description file (usually package.json).

This happens because the nearest package.json for a secondary entry point like @mui/material/styles is at node_modules/@mui/material/styles/package.json, which typically has no version field — the version lives in the parent node_modules/@mui/material/package.json.

How to reproduce

// rspack.config.js
const { SharePlugin } = require("@rspack/core").sharing;

module.exports = {
  plugins: [
    new SharePlugin({
      shared: {
        "@mui/material/styles": {}
      }
    })
  ]
};

With @mui/material installed, this produces a warning because node_modules/@mui/material/styles/package.json has no version.

Expected behavior

ProvideSharedPlugin should walk up from the secondary entry point's package.json to find the parent package's package.json (which has both name and version), and use the parent's version — but only when the shared key exactly matches <parent_name>/<relative_path>.

Upstream references

• webpack/webpack#15864 — canonical issue for this limitation
• webpack/webpack#13457 — acknowledged as bug by sokra
• webpack/webpack#12942 — earlier report

Prevalence

This pattern is used by MUI (150+ secondary entry points), Emotion/Preconstruct, Apollo Client, and historically Angular APF.

Relation to rspack#8388

The recursive search merged in rspack#8388 targets a different scenario in ConsumeSharedPlugin (monorepo hoisting / dual ESM+CJS). This issue is about ProvideSharedPlugin and the secondary entry point pattern specifically — the fix complements #8388 rather than overlapping.