/**
 * Request the assets loader and IncludeModules emit for the asset registry.
 *
 * React Native <= 0.86 ships this file and, on 0.86, resolves it directly (its
 * `exports` map has a `./Libraries/*` wildcard, so it works with package exports
 * on or off). React Native 0.87 removes the file and drops the `./*` wildcard, so
 * the request is remapped to `src/asset-registry.js` with a resolve alias (see
 * {@link getReactNativeAssetRegistryAlias}).
 *
 * Keeping this request unchanged across versions preserves the Module Federation
 * deep-import share key (`shared['react-native/']`) so hosts and remotes built
 * with different Re.Pack versions still share a single registry instance.
 */
export declare const ASSET_REGISTRY_REQUEST = "react-native/Libraries/Image/AssetRegistry";
type Resolver = (request: string, paths: string[]) => string;
/**
 * Resolves React Native's polyfill list, returning the same
 * `() => string[]` contract as the historic `rn-get-polyfills.js`.
 *
 * React Native <= 0.86 shipped `rn-get-polyfills.js` at the package root, which
 * re-exported `@react-native/js-polyfills` (a direct dependency of react-native).
 * 0.87 removed that file and dropped the dependency entirely, so the polyfills
 * are now only reachable through packages that still depend on them - see
 * {@link POLYFILLS_LOOKUP_CHAINS}.
 *
 * The polyfills are inlined into the emitted bundle, so they must be resolvable
 * for production bundles too - they cannot be treated as dev-only. `resolveFrom`
 * is injectable so the lookup chain can be exercised hermetically (the real
 * resolver leaks the surrounding install layout, e.g. pnpm's virtual store).
 */
export declare function resolveReactNativePolyfills(projectRoot: string, reactNativePath: string, resolveFrom?: Resolver): () => string[];
/**
 * Builds the `resolve.alias` entries that map {@link ASSET_REGISTRY_REQUEST} and
 * {@link ASSETS_REGISTRY_PACKAGE_REQUEST} to the relocated registry file on the
 * React Native >= 0.87 layout, so every request shares one registry (as Expo's
 * Metro config does).
 *
 * Returns `null` (no alias) whenever the legacy file already exists, or no
 * registry can be found at all. On <= 0.86 the legacy request resolves natively,
 * so injecting an alias there would mutate resolution for no benefit - and would
 * break the 0.86 `exports` wildcard path. The alias target is extensionless so
 * platform extensions (`.native.js`, `.ios.js`, ...) still apply.
 */
export declare function getReactNativeAssetRegistryAlias(reactNativePath: string): Record<string, string> | null;
/**
 * Builds the `resolve.alias` entries that keep React Native's internal deep
 * imports working when package exports are enabled (`enablePackageExports`).
 *
 * React Native <= 0.86 exposed its `exports` map with a `./*` / `./src/*`
 * wildcard, so deep requests such as
 * `react-native/src/private/featureflags/ReactNativeFeatureFlags` (imported by
 * `@react-native/virtualized-lists` and other first-party packages) resolved
 * through the exports map. React Native 0.87 narrowed the map to a small set of
 * explicit subpaths and dropped those wildcards, so the same deep requests no
 * longer match any export condition and resolution fails once package exports
 * are on. React Native still ships `src/private/**` on disk - it is simply not
 * exported - and no resolve condition can un-hide it, so the only way to keep
 * bundling with package exports enabled is to remap the prefix to the on-disk
 * directory. Aliasing to an absolute path bypasses the exports map entirely.
 *
 * Returns `null` (no alias) when `src/private` is already reachable through the
 * exports map (<= 0.86), when React Native declares no exports map at all, or
 * when the directory is absent - so this is a no-op on the legacy layout.
 */
export declare function getReactNativeDeepImportAliases(reactNativePath: string): Record<string, string> | null;
/**
 * Builds exact-match `resolve.alias` entries for the explicit subpath exports
 * React Native >= 0.87 declares, such as `react-native/setup-env` and
 * `react-native/react-private-interface`, whose files live under `src/` rather
 * than at the requested path.
 *
 * These requests only resolve through the `exports` map, which is skipped when
 * package exports are disabled (Repack's default) and when `react-native` is
 * aliased to its directory - the alias rewrites the request to a path that
 * doesn't exist. React Native 0.88's own packages (e.g.
 * `@react-native/virtualized-lists`) and Expo SDK 58 import these entry points,
 * so each one is aliased to the file its `default` export condition points to.
 * Only that condition is read: React Native's other conditions on these
 * subpaths are type-only. The targets keep their `.js` extension, as package
 * exports resolve to exact files.
 *
 * Returns `null` (no alias) when React Native declares no such subpaths
 * (<= 0.86) or no exports map at all.
 */
export declare function getReactNativeSubpathExportAliases(reactNativePath: string): Record<string, string> | null;
export {};