fix(babel): normalize resolved paths to POSIX so Windows rewrites work

[YevheniiKotyrlo]

Summary

The babel import plugin's relative-import rewriting silently no-ops on Windows. parseReactNativeSource / parseReactNativeWebSource resolve a relative source against the file being transformed and then match the result against forward-slash literals:

source = resolve(dirname(filename), source);
const internalPath = source.split("react-native/Libraries/Components/")[1];

path.resolve returns backslash-separated paths on Windows, so .split("react-native/Libraries/Components/") (and the react-native-web/dist split) never matches — internalPath is undefined, the function bails, and the import is left un-rewritten. The plugin's other cases (bare react-native / react-native-web specifiers) are plain string matches and are unaffected, so only relative imports break, and only on Windows.

This surfaces as three tests failing on Windows while green on the Linux/macOS CI:

• src/__tests__/babel/react-native.test.ts › 7. import View from '../View/View';
• src/__tests__/babel/react-native-web.test.ts › 6. import View from '../View';
• src/__tests__/babel/react-native-web.test.ts › 17. const View = _interopRequireDefault(require('../View'));

Fix

Normalize the resolved path to POSIX separators before the forward-slash matching, via a small shared helper:

export function resolvePosix(...segments: string[]): string {
  return resolve(...segments).replace(/\\/g, "/");
}

parseReactNativeSource and parseReactNativeWebSource now call resolvePosix instead of resolve. The resolve semantics are unchanged — each keeps its own base (dirname(filename) vs filename); only the separator is normalized.

import-plugin.ts's isFromThisModule is intentionally left on path.resolve: it compares two OS-native absolute paths (state.filename.startsWith(thisModuleDist)), so both sides share the platform separator and it already works — normalizing only one side would break it.

Test plan

• The three previously-failing relative-import cases now pass on Windows and remain green on POSIX. src/__tests__/babel/ goes from 2 suites failing / 3 tests to 4 suites / 35 tests.
• src/__tests__/babel/helpers.test.ts asserts against Windows-shaped literals, so it fails on any host when the normalization is removed. Deleting toPosixPath's body turns 8 tests red across 3 suites.
• yarn test, yarn typecheck, yarn eslint and prettier --check all pass.

Why the helper is split in two

An earlier version of this exposed a single resolvePosix(...segments) that fused path.resolve into the normalization. That is untestable on the platform that matters: resolve only emits a backslash on Windows, so on Linux the normalization has nothing to act on and an assertion through resolvePosix passes with the fix deleted. I measured that — emulating the CI runner, the fused helper's tests stay green under every mutation, including removing the fix entirely.

Since every job in ci.yml is ubuntu-latest (with one macos-15 for the iOS build) and there is no Windows runner anywhere, a guard that only fails on Windows guards nothing here. toPosixPath is a pure string transform, so it can be fed "C:\\…" directly and fails everywhere.

The platform gate sits in resolvePosix, not in toPosixPath. A backslash is a legal filename character on POSIX, so rewriting one there would corrupt a path that was already correct — but putting that check inside toPosixPath would make it an identity on Linux and put it back out of CI's reach. Splitting them gives both: the pure transform is testable on any host, and the rewrite only ever runs where path.resolve can actually produce a backslash.

Worth considering separately: adding windows-latest to the test job would make this class of bug visible at all. Without it, this fix is guarded only by tests the project's own runner cannot fail. Happy to send that as its own PR.

Two adjacent things I did not touch

• src/metro/resolver.ts solves the same "find a package inside a host path" problem the other way, building its markers from sep. POSIX normalization is right here specifically, because the resolved path is re-emitted as a module specifier at react-native.ts:26 and a specifier must use forward slashes — a sep marker would leave View\View in the rebuilt string. But the package now has two conventions for one problem, and that is worth a decision.
• import-plugin.ts:29-36's isFromThisModule guard is dead on every OS, and not for separator reasons: thisModuleDist is absolute while Metro passes state.filename project-relative (Transformer.js:68 does path.relative(projectRoot, filePath)), so the startsWith can never match. Deliberately out of scope here — flagging it because it sits three lines from this change.