Inline Platform within RN’s Babel preset (#57848)

[robhogan]

Summary:

Adds a React Native-owned Babel plugin that inlines Platform.OS and
Platform.select(...), from
react-native/babel-preset at the front of the preset's plugin list (importantly, before
the preset lowers ES modules to CommonJS).

Metro already inlines Platform, but its matcher (metro-transform-plugins'
inline-plugin via createInlinePlatformChecks) runs after ESM has been
lowered to CommonJS. By then a genuine import {Platform} from 'react-native'
has become _reactNative.Platform.OS and provenance is obscured and fragile to track. Metro compensates by matching on the local
identifier spelling - so Platform.OS inlines whether or not Platform is
actually React Native's, and a genuine deep or RN-relative import may be missed entirely.

Platform inlining is in any case much more of an RN concern than a Metro one - it has to be aware of RN APIs and module names, and even the module’s path.

This plugin recognises:

• import {Platform} from 'react-native' (including aliased imports)
• import * as RN from 'react-native', uses of RN.Platform
• import P from 'react-native/Libraries/Utilities/Platform'
• the equivalent require forms, plus destructuring and immutable aliases
• RN's internal relative imports, e.g. ../../Utilities/Platform

…and deliberately does not recognise anything it cannot prove - a bare
Platform.OS global, React.Platform.OS, or a same-named import from another
package.

Metro's late matcher is left fully enabled and remains responsible for
those historical forms, so this change is purely additive: it inlines genuine
imports Metro was missing, and changes nothing Metro already handled. Metro’s plugin will be deprecated and removed in future.

Notable details:

• Relative RN imports are resolved lexically, with no filesystem access and no
  platform-extension resolution — the identity we need is the extension-less
  module <rn-root>/Libraries/Utilities/Platform, and Metro picks
  Platform.ios.js / Platform.android.js later. The RN package root is
  identified by directory name, which covers node_modules/react-native,
  packages/react-native and pnpm layouts alike, and rejects
  react-native-web and friends (who would be expected to adjust the paths in their forks)
• Imports are left in place. Removing them would change dependency collection,
  so it is handled separately.
• A no-platform build (null, or the empty string that RN's Jest preprocessor
  passes) is a no-op — inlining Platform.OS to "" would be wrong.
• The plugin source is added to the preset's getCacheKey so edits invalidate Metro's transform cache.

Changelog:
[General][Changed] - Inline Platform.OS and Platform.select(...) for
React Native Platform imports during the Babel preset, covering some cases that were previously left un-inlined.

Reviewed By: huntie

Differential Revision: D114647943

[meta-codesync]

@robhogan has exported this pull request. If you are a Meta employee, you can view the originating Diff in D114647943.

[retyui]

@robhogan I guess my PR to Metro doesn't make sense at all react/metro#1732 , right ?

[retyui]

I believe you should avoid adding this plugin in tests (Jest) environment

As devs need to be able to mock Platform.OS value

[robhogan]

Thanks - I hadn't considered that and worth checking, but I think we're safe. The inline plugin is a no-op unless caller.platform is a non-empty string - i.e, it only inlines if platform is explicitly set at transform time.

The RN jest preset does not set platform - it uses babel-jest with no overrides

react-native/packages/jest-preset/jest-preset.js

Lines 31 to 32 in 2dc5e3a

	transform: {
	'^.+\\.(js|ts|tsx)$': 'babel-jest',

That picks up Babel configs, but we don't encourage setting platform there either, and the template doesn't:

https://github.com/react-native-community/template/blob/ed3802bac7e7af9571c984d912b54262d7ce49c5/template/babel.config.js

expo-jest does set a platform, but Expo use their own preset entirely (I've added a line exporting this plugin so they can reuse it)

[robhogan]

@robhogan I guess my PR to Metro doesn't make sense at all react/metro#1732 , right ?

This is intended to replace Metro's plugin, but all credit to you for identifying the problem here, it was reviewing that PR that led me to conclude that inlining living where it does/did in Metro is just unsalvageable. There are no good options that late in the transform pipeline (dealing with experimentalImportSupport, Expo ESM and Babel ESM after the fact, correctly, is hard, arguably impossible without graph context). Dealing with relative paths ends up either coupling too tightly to RN and being fragile, or leaving too many potential false positives.

Here, we can safely couple to RN, and OOT forks can modify their fork of the plugin if they need.

[meta-codesync]

This pull request has been merged in 40c0612.