React Native 0.80では、React NativeのJavaScript APIに2つの重要な変更を導入します — deep importsの非推奨化と、新しいStrict TypeScript APIです。これらは、APIを正確に定義し、ユーザーとフレームワークに信頼できる型安全性を提供するための継続的な取り組みの一部です。
要点
- Deep importsの非推奨化: 0.80から、react-nativeパッケージからのdeep importsに対して非推奨警告を導入します。
- オプトインStrict TypeScript API: ソースからのTypeScript型と、TypeScript下での新しいパブリックAPIベースラインに移行します。これにより、より強力で将来性のある型精度が実現され、一度限りの破壊的変更となります。プロジェクトのtsconfig.jsonのcompilerOptionsを通じてオプトインしてください。
将来のReact NativeリリースでデフォルトでStrict TypeScript APIを有効にする前に、これらの変更がすべての人にとって機能することを確実にするため、時間をかけてコミュニティと協力していきます。
何が変わるのか、そしてなぜ
React NativeのパブリックJavaScript API — つまりimport 'react-native'で取得するもの — を改善し、安定化させるために取り組んでいます。
歴史的に、私たちはこれを近似してきました。React NativeはFlowで書かれていますが、コミュニティは長い間オープンソースでTypeScriptに移行しており、これがパブリックAPIが消費され、互換性が検証される方法です。
私たちの型は（愛情を込めて）コミュニティによって貢献され、その後私たちのコードベースにマージされ、整合されました。しかし、これらは手動メンテナンスに依存し、自動化ツールがなかったため、正確性のギャップが生じていました。
さらに、私たちのパブリックJS APIは、モジュール境界の観点で不十分に定義されていました — 例えば、内部の'react-native/Libraries/'のdeep importsはアプリコードからアクセス可能でしたが、これらの内部を更新する際に頻繁に変更される可能性がありました。
0.80では、deep importsを非推奨化し、TypeScriptでの新しい生成されたAPIベースラインへのユーザーオプトインを導入することで、これらの問題に対処しています。これをStrict TypeScript APIと呼んでいます。
最終的に、これは将来的に安定したReact Native APIを提供するための基盤です。
react-nativeからのdeep importsの非推奨化
今日私たちがAPIに加える主な変更は、deep importsの使用を非推奨化することです（RFC）。ESLintとJSコンソールで警告が表示されます。
値と型のdeep importsは、react-nativeのルートインポートに更新する必要があります。
import { Alert } from 'react-native/Libraries/Alert/Alert';
import { Alert } from 'react-native';
この変更により、JavaScript APIの総表面積が、私たちが制御し、将来のリリースで安定化できる固定されたエクスポートセットに削減されます。
私たちは0.82でこれらのインポートパスの削除を目標としています。
APIフィードバック
一部のAPIはルートでエクスポートされておらず、deep importsなしでは利用できなくなります。私たちはオープンフィードバックスレッドを設けており、パブリックAPIでのエクスポートを最終化するためにコミュニティと協力していきます。フィードバックをお寄せください！
オプトアウト
将来のリリースでReact NativeのAPIからdeep importsを削除することを目指しており、これらはルートインポートに更新されるべきであることにご留意ください。
警告のオプトアウト
ESLint
overridesを使用してno-deep-importsルールを無効にします。
.eslintrc.js
overrides: [
{
files: ['*.js', '*.jsx', '*.ts', '*.tsx'],
rules: {
'@react-native/no-deep-imports': 0,
},
},
],
コンソール警告
@react-native/babel-presetにdisableDeepImportWarningsオプションを渡します。
babel.config.js
module.exports = {
presets: [
[
'module:@react-native/babel-preset',
{ disableDeepImportWarnings: true }
]
],
};
Metroキャッシュをクリアするために--reset-cacheでアプリを再起動します。
npx @react-native-community/cli start --reset-cache
警告のオプトアウト（Expo）
ESLint
overridesを使用してno-deep-importsルールを無効にします。
.eslintrc.js
overrides: [
{
files: ['*.js', '*.jsx', '*.ts', '*.tsx'],
rules: {
'@react-native/no-deep-imports': 0,
},
},
];
コンソール警告
babel-preset-expoにdisableDeepImportWarningsオプションを渡します。
babel.config.js
module.exports = function(api) {
api.cache(true);
return {
presets: [
[
'babel-preset-expo',
{ disableDeepImportWarnings: true }
]
],
};
};
Metroキャッシュをクリアするために--clearでアプリを再起動します。
npx expo start --clear
Strict TypeScript API（オプトイン）
Strict TypeScript APIは、react-nativeパッケージの新しいTypeScript型のセットで、tsconfig.jsonを通じてオプトインできます。既存のTS型と並行してこれらを提供しているため、準備ができたときに移行を選択できます。
新しい型は以下の特徴があります：
- ソースコードから直接生成 — カバレッジと正確性が向上し、より強力な互換性保証が期待できます。
react-nativeのindexファイルに制限 — パブリックAPIをより厳密に定義し、内部ファイル変更時にAPIを破壊しないことを意味します。
コミュニティの準備が整ったとき、Strict TypeScript APIは将来のデフォルトAPIとなります — deep imports削除と同期されます。これは、React Nativeの将来の安定したJS APIに備えることができるため、オプトインを開始することをお勧めします。
tsconfig.json
{
"extends": "@react-native/typescript-config",
"compilerOptions": {
...
"customConditions": ["react-native-strict-api"]
}
}
内部動作
これにより、TypeScriptは以前のtypes/ディレクトリ（手動メンテナンス）の代わりに、新しいtypes_generated/ディレクトリからreact-native型を解決するよう指示されます。TypeScriptやエディタの再起動は不要です。
破壊的変更：Deep importsが許可されない
上記のように、Strict TypeScript API下の型は、メイン'react-native'インポートパスからのみ解決可能になり、上記の非推奨化に従ってパッケージカプセル化を強制します。
import { Alert } from 'react-native/Libraries/Alert/Alert';
import { Alert } from 'react-native';
主な利点
私たちが慎重にメンテナンスしているReact Nativeのindex.jsファイルのエクスポートにパブリックAPIを限定しました。これは、コードベースの他の場所でのファイル変更がもはや破壊的変更にならないことを意味します。
破壊的変更：一部の型名/形状が変更されました
型は手動メンテナンスではなく、ソースから生成されるようになりました。これにより：
- コミュニティ貢献型から蓄積された差異を整合し、ソースコードの型カバレッジも向上させました。
- 簡素化や曖昧さの軽減の余地があった場合、意図的に一部の型名と型形状を更新しました。
主な利点
型がReact Nativeのソースコードから生成されるようになったため、型チェッカーが特定のreact-nativeバージョンに対して常に正確であることを確信できます。
例：より厳密なエクスポートシンボル
Linking APIは、2つのエクスポートではなく、単一のインターフェースになりました。これは他の多くのAPI（ドキュメント参照）でも同様です。
import { Linking, LinkingStatic } from 'react-native';
function foo(linking: LinkingStatic) {}
foo(Linking);
import { Linking } from 'react-native';
function foo(linking: Linking) {}
foo(Linking);
例：修正された/より完全な型
以前の手動型定義では、型ギャップの機会が残されていました。生成されたFlow → TypeScriptでは、これらはもはや存在しません（そしてソースでは、マルチプラットフォームコードに対するFlowの追加型検証の恩恵を受けます）。
import { Dimensions } from 'react-native';
const { densityDpi } = Dimensions.get();
その他の破壊的変更
すべての破壊的型変更とコードの更新方法を詳述したドキュメントの専用ガイドを参照してください。
ロールアウト
React Nativeへの破壊的変更は、開発者がアプリで更新するのに時間がかかることを理解しています。
現在 — オプトイン開始（0.80）
"react-native-strict-api"オプトインは0.80リリースで安定しています。これは一度限りの移行です。
次のいくつかのリリースにわたって、アプリとライブラリが独自のペースでオプトインすることを目指しています。
どちらのモードでも、実行時にアプリに変更はありません — これはTypeScript解析のみに影響します。
そして、専用フィードバックスレッドを通じて、不足しているAPIに関するフィードバックを受け付けます。
推奨
Strict TypeScript APIは将来のデフォルトAPIになります。時間があれば、アプリやライブラリを将来に備えるために、tsconfig.jsonでオプトインをテストすることをお勧めします。
これにより、Strict API下でアプリに導入される型エラーがあるかどうかを即座に評価できます。何もない場合もあります（！）— その場合は準備完了です。
将来 — デフォルトでStrict TypeScript API
将来的に、すべてのコードベースでStrict APIの使用を要求し、レガシー型を削除します。これのタイムラインはコミュニティフィードバックに基づきます。
少なくとも次の2つのReact Nativeリリースでは、Strict APIはオプトインのままです。
FAQ
現在サブパスインポートを使用しています。何をすべきですか？
ルート'react-native'インポートパスに移行してください。サブパスインポート（例：'react-native/Libraries/Alert/Alert'）はプライベートAPIになります。
React Native内の実装ファイルへのアクセスを防がなければ、安定したJavaScript APIを提供できません。
私たちの非推奨警告がコミュニティフィードバックを促すことを望んでおり、アプリにとって重要なコードパスを公開していないと思われる場合は、中央集約ディスカッションスレッドを通じて提起できます。正当化される場合、APIをindexエクスポートに昇格させる可能性があります。
ライブラリメンテナーです。この変更は私にどのような影響を与えますか？
tsconfig.jsonは直接のコードベースにのみ影響するため、アプリとライブラリの両方が独自のペースでオプトインできます。
通常、node_modulesはReact NativeプロジェクトのTypeScriptサーバーによる検証から除外されます。したがって、パッケージのエクスポートされた型定義が真実のソースです。
💡 フィードバックをお待ちしています！ 変更されたサブパスインポートと同様に、Strict APIで統合問題が発生した場合は、GitHubでお知らせください。
これはReact Nativeの最終APIを保証しますか？
残念ながら、まだです。0.80では、React Nativeの既存のJS APIベースラインがTypeScriptを通じて正確に消費できるようにツール投資を行いました — 将来の安定した変更を可能にします。
私たちは、あなたが知っていて愛している既存のAPIを形式化しています。
将来的に、各言語サーフェス全体で、現在コアで提供しているAPIを最終化するアクションを取ります。API変更はRFC/アナウンスを通じて伝達され、通常は非推奨サイクルを経ます。
なぜReact NativeはTypeScriptで書かれていないのですか？
React NativeはMetaのコアインフラストラクチャです。一般的なオープンソース利用可能性に達する前に、Family of Appsでマージされたすべての変更をテストしています。
この規模と機密性では、正確性が重要です。結論として、FlowはTypeScriptよりも優れたパフォーマンスと厳密性を提供し、React Native向けの特定のマルチプラットフォームサポートを含んでいます。
謝辞
これらの変更は、Iwo Plaza、Jakub Piasecki、Dawid Małecki、Alex Hunt、Riccardo Cipolleschiによって実現されました。追加のヘルプと入力をいただいたPieter Vanderwerff、Rubén Norte、Rob Hoganにも感謝します。
詳細を学ぶ
トークを見る！ App.js 2025で、Strict TypeScript APIの背後にある動機と作業について詳しく共有しました。
YouTubeで見る