Avançando para uma API JavaScript Estável (Novas Mudanças na Versão 0.80) · React Native

overrides:[
{
files:["*.js","*.jsx","*.ts","*.tsx"],
rules:{
"@react-native/no-deep-imports":0,
},
},
];
Avisos no console
Passe a opção disableDeepImportWarnings para o @react-native/babel-preset.

babel.config.js
module.exports = {
  presets: [
    ['module:@react-native/babel-preset', { disableDeepImportWarnings: true }]
  ]
};

Rode seu aplicativo com --reset-cache para limpar o cache do Metro.

npx @react-native-community/cli start --reset-cache
Pass the disableDeepImportWarnings option to babel-preset-expo.
babel.config.js
module.exports = function (api) {
  api.cache(true);
  return {
    presets: [
Reinicie seu aplicativo com --clear para limpar o cache do Metro.
API TypeScript Estrita (opção)
A API TypeScript Estrita é um novo conjunto de tipos TypeScript no pacote react-native, que pode ser habilitado via seu arquivo tsconfig.json. Estamos enviando esses tipos junto com nossos tipos TS existentes, o que significa que você pode optar por migrar quando estiver pronto.
Os novos tipos são:

Gerados diretamente a partir de nosso código-fonte — melhorando a cobertura e a precisão, então você pode esperar garantias mais fortes de compatibilidade.
Limitado ao arquivo index do react-native — definindo nossa API pública com mais rigor, o que significa que não quebraremos a API quando fizermos alterações internas nos arquivos.

Quando a comunidade estiver pronta, a API TypeScript Estrita se tornará nossa API padrão no futuro — sincronizada com a remoção de importações profundas. Isso significa que é uma boa ideia começar a optar por ela, pois você estará pronto para a futura API JS estável do React Native.

tsconfig.json

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



Isso instruirá o TypeScript a resolver os tipos react-native do novo diretório types_generated/, em vez do anteriormente mantido manualmente types/. Não é necessário reiniciar o TypeScript ou seu editor.


Quebras: Importações profundas não são permitidas
Como acima, os tipos sob a API TypeScript Estrita agora só podem ser resolvidos do caminho de importação principal 'react-native', impulsionando o encapsulamento do pacote conforme nossa depreciação acima.



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


import {Alert} from 'react-native';





Nós limitamos nossa API pública às exportações do arquivo index.js do React Native, que mantemos cuidadosamente. Isso significa que alterações em outros arquivos no nosso códigobase não serão mais mudanças quebradoras.


Quebras: Alguns nomes de tipo / formas de tipo mudaram
Os tipos agora são gerados a partir da fonte, em vez de serem mantidos manualmente. Ao fazer isso:

Nós alinhamos diferenças que se acumularam dos tipos contribuídos pela comunidade - e também aumentamos a cobertura de tipo do nosso código-fonte.
Intencionalmente atualizamos alguns nomes de tipo e formas de tipo, onde havia espaço para simplificar ou reduzir ambiguidade.



Como os tipos agora são gerados a partir do código-fonte do React Native, você pode ter certeza de que o typechecker é sempre preciso para uma determinada versão do react-native.
Exemplo: Símbolos exportados mais estritos
A API Linking agora é um único interface, em vez de duas exportações. Isso se aplica a vários outros APIs (veja os docs).



import {Linking, LinkingStatic} from 'react-native';

function foo(linking: LinkingStatic) {}
foo(Linking);

import {Linking} from 'react-native';

function foo(linking: Linking) {}
foo(Linking);


Exemplo: Tipos fixos / mais completos
As definições de tipo manuais anteriores deixavam lacunas de tipos. Com a geração Flow → TypeScript, essas lacunas não existem mais (e na fonte, beneficiam-se da validação adicional de tipos do Flow para código multiplataforma).
1 import {Dimensions} from 'react-native';
2
3 const {densityDpi} = Dimensions.get();
Outras mudanças que quebram a compatibilidade
Consulte nosso guia dedicado na documentação, que detalha todas as mudanças de tipos que quebram a compatibilidade e como atualizar seu código.
Lançamento
Apreciamos que qualquer mudança que quebre a compatibilidade no React Native levará tempo para os desenvolvedores atualizarem em seus aplicativos.
Agora — Lançamento opcional (0.80)
A opção de entrada "react-native-strict-api" é estável na versão 0.80.

Isto é uma migração única. Nosso objetivo é que os aplicativos e bibliotecas optem por entrar em seu próprio ritmo nas próximas duas ou três releases.
Sob qualquer modo, nada mudará para seu aplicativo em tempo de execução — isso afeta apenas a análise do TypeScript.
E, receberemos feedback sobre APIs ausentes via nosso tópico dedicado de feedback.


O Strict TypeScript API se tornará nossa API padrão no futuro.
Se você tiver tempo, vale a pena testar o opt-in agora em seu tsconfig.json, para garantir que seu aplicativo ou biblioteca esteja preparado para o futuro. Isso avaliará imediatamente se existem quaisquer erros de tipo introduzidos no seu aplicativo sob a API Strict. Pode não haver nenhum (!) — nesse caso, você está pronto para ir.

Futuro — API TypeScript Stric por padrão
No futuro, exigiremos que todas as bases de código usem nossa API Strict e removeremos os tipos legados.
A linha do tempo para isso será baseada em feedback da comunidade. No mínimo, nas próximas duas versões do React Native, a API Strict permanecerá como uma opção.
Perguntas Frequentes

Estou usando importações de subpath hoje. O que devo fazer?

Faça a migração para o caminho de importação raiz 'react-native'.

Importações de subpath (por exemplo, 'react-native/Libraries/Alert/Alert') estão se tornando APIs privadas. Sem impedir o acesso a arquivos de implementação dentro do React Native, não podemos oferecer uma API JavaScript estável.
Desejamos que nossos avisos de depreciação incentivem feedback da comunidade, que pode ser levantado através de nosso fio de discussão centralizado, se você acreditar que não estamos expor caminhos de código cruciais para seu aplicativo. Quando justificado, podemos promover APIs ao índice export.


Sou um mantenedor de bibliotecas. Como essa mudança me afeta?

Aplicativos e bibliotecas podem optar por aderir ao seu próprio ritmo, já que tsconfig.json afetará apenas a base de código imediata.

No React Native project, geralmente o node_modules é excluído da validação pelo servidor TypeScript. Portanto, as definições de tipos exportadas por seu pacote são a verdadeira fonte.
💡 Queremos feedback! Assim como mudanças em importações de subpath, se você encontrar quaisquer problemas de integração com a API Strict, nos avise no GitHub.

Isso garante uma API final para o React Native ainda?

Lamentavelmente, não ainda. Em 0.80, fizemos um investimento em ferramentas para que a base de API JS existente do React Native possa ser consumida precisamente via TypeScript — habilitando mudanças futuras estáveis. Estamos formalizando a API existente que você conhece e ama.
No futuro, tomaremos medidas para finalizar as APIs que atualmente oferecemos no núcleo — em cada superfície de linguagem. Mudanças na API serão comunicadas por meio de RFCs/anúncios, geralmente através de um ciclo de depreciação.

Por que o React Native não é escrito em TypeScript?

O React Native é infraestrutura de núcleo na Meta. Testamos cada alteração incorporada em nossa Família de Aplicativos antes de serem disponibilizadas para fonte aberta geral.
Nessa escala e sensibilidade, a correção importa. O ponto principal é que o Flow oferece desempenho superior e maior rigidez do que TypeScript, incluindo suporte específico multiplataforma para React Native.
Agradecimentos
Essas mudanças foram possíveis graças a Iwo Plaza, Jakub Piasecki, Dawid Małecki, Alex Hunt e Riccardo Cipolleschi.
Agradecimentos também a Pieter Vanderwerff, Rubén Norte e Rob Hogan por sua ajuda adicional e contribuições.

  

    
Acompanhe a palestra!
Compartilhamos uma análise profunda sobre nossas motivações e o trabalho
por trás da API Strict TypeScript em 
App.js 2025.
    Ver no YouTube