Enabling "Strict TypeScript API" doesn't restrict access to `react-native/Libraries/*`

[kraenhansen]

Description

Setting react-native-strict-api doesn't restrict access to sub-paths like react-native/Libraries/Alert/Alert.

Steps to reproduce

In an attempt to verify the restriction of types by setting the react-native-strict-api in the customCondition of the tsconfig.json I followed the guide on the React Native Blog: https://reactnative.dev/blog/2025/06/12/moving-towards-a-stable-javascript-api#breaking-deep-imports-are-disallowed and found that I could still access APIs through deep imports:

src/index.ts

import { Alert } from "react-native/Libraries/Alert/Alert";

package.json

{
 "name": "react-native-ts-test",
 "private": true,
 "version": "0.1.0",
 "scripts": {
 "build": "tsc --noEmit"
 },
 "devDependencies": {
 "@react-native/typescript-config": "^0.81.1",
 "typescript": "5.9.2",
 "jest": "^30.1.2"
 },
 "dependencies": {
 "react-native": "^0.81.1"
 }
}

tsconfig.json

{
 "extends": "@react-native/typescript-config",
 "compilerOptions": {
 "customConditions": ["react-native-strict-api"]
 },
 "include": ["src/index.ts"]
}

See the resolution (running npx resolution-explorer)

Explicitly specified module resolution kind: 'Bundler'. 
Resolving in CJS mode with conditions 'import', 'types', 'react-native-strict-api'. 
File '/Users/kraen.hansen/Repositories/react-native-ts-test/src/package.json' does not exist. 
Found 'package.json' at '/Users/kraen.hansen/Repositories/react-native-ts-test/package.json'. 
Loading module 'react-native/Libraries/Alert/Alert' from 'node_modules' folder, target file types: TypeScript, JavaScript, Declaration, JSON. 
Searching all ancestor node_modules directories for preferred extensions: TypeScript, Declaration. 
Directory '/Users/kraen.hansen/Repositories/react-native-ts-test/src/node_modules' does not exist, skipping all lookups in it. 
Found 'package.json' at '/Users/kraen.hansen/Repositories/react-native-ts-test/node_modules/react-native/package.json'. 
Entering conditional exports. 
Matched 'exports' condition 'react-native-strict-api'. 
package.json scope '/Users/kraen.hansen/Repositories/react-native-ts-test/node_modules/react-native' explicitly maps specifier './Libraries/Alert/Alert' to null. 
Failed to resolve under condition 'react-native-strict-api'. 
Saw non-matching condition 'react-native-strict-api-UNSAFE-ALLOW-SUBPATHS'. 
Matched 'exports' condition 'types'. 
Using 'exports' subpath './*' with target './Libraries/Alert/Alert.d.ts'. 
File '/Users/kraen.hansen/Repositories/react-native-ts-test/node_modules/react-native/Libraries/Alert/Alert.d.ts' exists - use it as a name resolution result. 
'package.json' has a 'peerDependencies' field. 
Resolving real path for '/Users/kraen.hansen/Repositories/react-native-ts-test/node_modules/react-native', result 
'/Users/kraen.hansen/Repositories/react-native-ts-test/node_modules/react-native'. 
Failed to find peerDependency '@types/react'. 
Found 'package.json' at '/Users/kraen.hansen/Repositories/react-native-ts-test/node_modules/react/package.json'. 
Found peerDependency 'react' with '19.1.1' version. 
Resolved under condition 'types'. 
Exiting conditional exports. 
Resolving real path for '/Users/kraen.hansen/Repositories/react-native-ts-test/node_modules/react-native/Libraries/Alert/Alert.d.ts', result 
'/Users/kraen.hansen/Repositories/react-native-ts-test/node_modules/react-native/Libraries/Alert/Alert.d.ts'. 
======== Module name 'react-native/Libraries/Alert/Alert' was successfully resolved to 
'/Users/kraen.hansen/Repositories/react-native-ts-test/node_modules/react-native/Libraries/Alert/Alert.d.ts' with Package ID 
'react-native/Libraries/Alert/Alert.d.ts@0.81.1+react@19.1.1'. ======== 

Crucially, notice:

• package.json scope '/Users/kraen.hansen/Repositories/react-native-ts-test/node_modules/react-native' explicitly maps specifier './Libraries/Alert/Alert' to null. 👍
• Matched 'exports' condition 'types'. 😱
• Using 'exports' subpath './*' with target './Libraries/Alert/Alert.d.ts'. 😱

I verified this with multiple TypeScript versions: 5.0.2, 5.7.3, 5.9.2.

React Native Version

0.81.1

Affected Platforms

Build - MacOS, Build - Windows, Build - Linux

Output of npx @react-native-community/cli info

N/A

Stacktrace or Logs

N/A

MANDATORY Reproducer

https://github.com/react-native-community/reproducer-react-native

Screenshots and Videos

No response

[react-native-bot]

Warning

Missing reproducer: We could not detect a reproducible example in your issue report. Reproducers are mandatory and we can accept only one of those as a valid reproducer:

• For majority of bugs: send us a Pull Request with the RNTesterPlayground.js edited to reproduce your bug.
• If your bug is UI related: a Snack
• If your bug is build/upgrade related: a project using our Reproducer Template

You can read more about about it on our website: How to report a bug.

[huntie]

(Continuing offline discussion) Yeah this is pretty unexpected (and out of spec) behaviour from TypeScript and I'm pretty sure didn't repo a few months back 😅

Bug

Matched 'exports' condition 'react-native-strict-api'.
[...] explicitly maps specifier './Libraries/Alert/Alert' to null

The resolver algorithm should stop here!

User impact

Since TypeScript will auto-suggest and auto-import react-native subpaths regardless of when "react-native-strict-api" is set, it breaks our encapsulation guarantee for the Strict TypeScript API.

Path forward

• Current plan: We are planning to swap how our "exports" conditions are stacked when we enable our Strict TypeScript API by default. This should fix things, as the legacy types will no longer match under "types" nor "default", and TS won't be able to fall back to it.
• Or, we bisect this with past TypeScript versions and see if it is a regression — raising to Microsoft as a bug if so.

[kraenhansen]

I confirmed the TypeScript compiler doesn't match the behavior of Node.js and filed an issue with a minimal reproduction: microsoft/TypeScript#62439

[kraenhansen]

The TS team added their Awaiting More Feedback label to the issue:

This means we'd like to hear from more people who would be helped by this feature

It would be great if we could draw a bit more attention to the issue 🤔

[react-native-bot]

This issue is stale because it has been open for 180 days with no activity. It will be closed in 7 days unless you comment on it or remove the "Stale" label.

[kraenhansen]

Update: The upstream TypeScript issue (microsoft/TypeScript#62439) has been closed as completed. The fix landed in TypeScript 6.0: when a custom condition maps to null, the resolver now correctly stops instead of falling back to the default condition.

I verified this with a minimal reproduction: TypeScript 5.9.3 (latest 5.x) still has the bug, but TypeScript 6.0.1-rc correctly rejects the import, matching Node.js runtime behavior.

This means the "react-native-strict-api" condition should work as intended once consumers upgrade to TypeScript 6.0.