docs: fix non-existent bridge-react/react import path

[Gmendesfonseca]

Description

The Producer API and Consumer API tables in the React Bridge getting-started guide point readers at @module-federation/bridge-react/react. That subpath is not in the package's exports map, so an import copied from these tables fails to resolve:

$ node -e "require.resolve('@module-federation/bridge-react/react')"
MODULE_NOT_FOUND

git log -S'"./react"' -- packages/bridge/bridge-react/package.json returns no commits, so this is a path that never existed rather than one that was removed and needs restoring. Neither of the two open PRs that modify that exports map (#4837, #4869) adds it.

The correct entry point for the legacy (React 16/17) createBridgeComponent, for createRemoteAppComponent and for lazyLoadComponentPlugin is the package root:

• apps/router-demo uses the package root for all six of its createBridgeComponent / createRemoteAppComponent imports, and /v18, /v19 and /plugin for the rest. /react appears zero times.
• The sibling load-app.mdx and export-app.mdx guides already use the package root in their code samples.

So the getting-started tables currently contradict both the working examples and the neighbouring pages. A reader following the entry-point tables — the first concrete instruction on the page — hits a module resolution error before anything else.

This PR replaces all 9 occurrences across the English, Simplified Chinese and Brazilian Portuguese pages.

This is a documentation-only change. It does not change runtime behavior or the public API.

Validation

• prettier --check apps/website-new/docs/{en,zh,pt-BR}/guide/bridge/react/getting-started.mdx — all matched files use Prettier code style

Related Issue

N/A — documentation-only correction.

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.

[changeset-bot]

⚠️ No Changeset found

Latest commit: cc4d431

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

[2heal1]

Thanks for fixing the invalid @module-federation/bridge-react/react paths. The root entry is correct for createBridgeComponent (React 16/17) and createRemoteAppComponent.

For lazyLoadComponentPlugin, could we use its dedicated public entry instead?

import { lazyLoadComponentPlugin } from '@module-federation/bridge-react/lazy-load-component-plugin';

The package root currently includes the router-aware component implementation and therefore resolves the optional react-router-dom peer dependency. The dedicated entry avoids that router
coupling and provides a clearer import path for plugin-only usage. Although /data-fetch is also router-free, it is a broader aggregation entry.

This investigation also highlighted an issue in our current entry-point design: importing an unrelated API from the package root can unexpectedly bring in router dependencies. We are aware
of this limitation and are planning to improve the entry-point isolation and overall import experience in a follow-up.

For this PR, please update the corresponding row in all three locales to:

@module-federation/bridge-react/lazy-load-component-plugin

[Gmendesfonseca]

@2heal1 Thanks — updated in all three locales (en, zh, pt-BR), pushed as cc4d431.

The Consumer API row for lazyLoadComponentPlugin now reads:

@module-federation/bridge-react/lazy-load-component-plugin

Your reasoning checks out against the source: the root src/index.ts re-exports createRemoteAppComponent from ./remote/router-component, so pulling the plugin off the root drags the optional react-router-dom peer along with it.

src/plugins/lazy-load-component-plugin.ts only imports from ../lazy and @module-federation/runtime, and ./lazy-load-component-plugin is already a first-class entry — present in exports, typesVersions, and the vite.config.ts entry map — so nothing else had to change.

One thing worth flagging for the entry-point follow-up you mentioned: the getting-started table is now the only place in the docs that points at the dedicated entry.

guide/bridge/react/load-component.mdx, guide/bridge/overview.mdx and _components/data-fetch/consumer.mdx still import lazyLoadComponentPlugin from @module-federation/bridge-react/data-fetch. Since you noted /data-fetch is router-free but a broader aggregation entry, I've left those alone to keep this PR scoped — happy to align them here in a follow-up commit if you'd prefer the docs consistent now rather than as part of the entry-point rework.

prettier --check still passes on all three files.