Summary

This fixes provider selection for import: false shared modules when the shared scope contains multiple providers for the same package.

Previously, the remote entry bridge picked the first provider from the shared scope object. That made the selected shared module depend on object key order rather than the configured share strategy, provider load state, version ordering, and strict version behavior.

When import: false shared modules are configured, the generated remote entry imports the public runtime share helper and emits a small bridge for selecting providers before seeding the __mf_module_cache__ entry.

This aligns the import: false bridge with the documented shareStrategy behavior for version-first and loaded-first.

Problem

The import: false bridge selected a provider like this:

const provider = versions && versions[Object.keys(versions)[0]];

When multiple providers existed for the same shared package, this could select whichever version appeared first in the object.

Example failure before this change:

const versions = {
  '18.3.1': react18Provider,
  '19.2.0': react19Provider,
};

If 18.3.1 was inserted first, Object.keys(versions)[0] selected the React 18 provider. A remote configured with react as singleton, import: false, and requiredVersion: '^19.0.0' could then seed __mf_module_cache__.share['default:react'] with React 18 before the exposed module imported React. Since singleton cache entries are reused, later shared imports could keep reading the wrong provider instead of the React 19 provider expected by version-first.

The generated share config also did not include strictVersion, so strict version mismatch handling was not preserved when the bridge delegated selection to the runtime helper.

Changes

• Added strictVersion to generated local and used shared configs in virtualRemoteEntry.ts and generateUsedSharedPreloadConfig.
• Added a small provider selection bridge emitted into remoteEntry only when import: false shared modules are configured: sharedProviderSelectionHelperCode and needsSharedProviderSelectionHelper.
• Imported share from @module-federation/runtime/helpers for that bridge so strategy, range, singleton, and strict-version decisions are delegated to the runtime getRegisteredShare path: runtimeShare import.
• Changed the base @module-federation/runtime alias to an exact match and added an import: false-only exact alias for @module-federation/runtime/helpers derived from the same runtime implementation: getRuntimeHelpersImplementation and config alias setup. This keeps custom implementation consumers and strict pnpm installs on one runtime package.
• For version-first, the bridge uses a selection-only provider map with loaded, loading, and lib neutralized before delegating to the runtime helper: __mfCreateProviderSelectionVersions. This prevents an already materialized lower version from winning over a higher compatible provider during import: false cache seeding.
• Updated the import: false bridge to use the helper instead of the first object key for both global share pre-seeding and shared init argument bridging.
• Added focused tests for provider selection, first-key removal, conditional helper imports, helper aliasing, custom runtime implementations, and global share scope pre-seeding in virtualRemoteEntry.test.ts and index.test.ts.