Skip to content

fix(nextjs-mf): Refine Module Federation shares and correct request keys #3791

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 2 commits into
base: app-router-share-filter
Choose a base branch
from

Conversation

ScriptedAlchemy
Copy link
Member

This commit addresses feedback on the previous module federation sharing updates:

  1. Corrects an issue where $ was used at the end of request strings in shared module configurations (e.g., unfetch$). This suffix is not standard for Module Federation share keys and has been removed. The import paths for these modules remain correct.

  2. Reinstates prefix-based shares in share-internals-client.ts for next/dist/shared/ (with include: /shared-runtime/) and next/ (with exclude: /dist/). This aligns with the preference for using broader shares where they suffice.

  3. Refines explicit shares in share-internals-client.ts:

    • Removed the explicit share for next/dist/shared/lib/shared-runtime.js as it is now covered by the reinstated prefix share.
    • Retained necessary explicit shares for React, Server Action client modules, polyfills mapping to Next.js internals, and core Next.js client utilities that map user-facing APIs (e.g., next/link) to specific internal next/dist/... paths.
  4. Reviewed explicit shares in share-internals-server.ts and confirmed their necessity due to specific internal import paths (for vendored React, Server Actions, aliased modules like @vercel/og, and core server APIs like next/headers) and the absence of broad prefix shares on the server side. No shares were removed from this file.

This approach ensures that module sharing is both comprehensive for critical Next.js internals and cleaner by preferring prefix shares where appropriate, while also correcting the format of request keys.

Description

Related Issue

Types of changes

  • Docs change / refactoring / dependency upgrade
  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)

Checklist

  • I have added tests to cover my changes.
  • All new and existing tests passed.
  • I have updated the documentation.

This commit addresses feedback on the previous module federation sharing
updates:

1.  Corrects an issue where `$` was used at the end of `request` strings
    in shared module configurations (e.g., `unfetch$`). This suffix is
    not standard for Module Federation share keys and has been removed.
    The `import` paths for these modules remain correct.

2.  Reinstates prefix-based shares in `share-internals-client.ts` for
    `next/dist/shared/` (with `include: /shared-runtime/`) and
    `next/` (with `exclude: /dist/`). This aligns with the preference
    for using broader shares where they suffice.

3.  Refines explicit shares in `share-internals-client.ts`:
    - Removed the explicit share for `next/dist/shared/lib/shared-runtime.js`
      as it is now covered by the reinstated prefix share.
    - Retained necessary explicit shares for React, Server Action client
      modules, polyfills mapping to Next.js internals, and core Next.js
      client utilities that map user-facing APIs (e.g., `next/link`) to
      specific internal `next/dist/...` paths.

4.  Reviewed explicit shares in `share-internals-server.ts` and confirmed
    their necessity due to specific internal `import` paths (for vendored
    React, Server Actions, aliased modules like `@vercel/og`, and core
    server APIs like `next/headers`) and the absence of broad prefix
    shares on the server side. No shares were removed from this file.

This approach ensures that module sharing is both comprehensive for
critical Next.js internals and cleaner by preferring prefix shares where
appropriate, while also correcting the format of request keys.
Copy link

changeset-bot bot commented May 21, 2025

⚠️ No Changeset found

Latest commit: 647de5e

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

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

This commit applies several corrections to the module federation
sharing configurations in `share-internals-client.ts` and
`share-internals-server.ts` based on recent feedback:

1.  **Removed Polyfill Sharing**:
    - All shared configurations for polyfills (e.g., `unfetch`,
      `isomorphic-unfetch`, `whatwg-fetch`, `object-assign`, `url`)
      have been removed from `share-internals-client.ts`.
    - Confirmed no such polyfill shares existed in
      `share-internals-server.ts`.

2.  **Restored Deterministic Key Generation**:
    - Reverted the key generation logic for shared module configurations
      in both `share-internals-client.ts` and `share-internals-server.ts`
      to be deterministic (based on shareKey, layer, and index),
      removing any `Math.random()` components.

3.  **Verified `nodeModulesReconstructedLookup`**:
    - Confirmed that React module configurations in `getReactGroupServer`
      within `share-internals-server.ts` correctly maintain
      `nodeModulesReconstructedLookup: false`, consistent with their
      previous state in the analyzed file version.

These changes ensure a more precise and deterministic approach to
sharing Next.js internals for Module Federation.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant