React Native 0.87 rende la Strict TypeScript API predefinita. Ecco l'ordine di aggiornamento.

React Native 0.87 è stato rilasciato l'11 agosto ed è la release con più breaking change che il framework abbia avuto da molto tempo. Il titolo principale è che la Strict TypeScript API, arrivata come anteprima opt-in già nella versione 0.80, è ora predefinita per ogni progetto. Insieme ad essa: supporto sperimentale per Swift Package Manager su iOS, supporto di prima classe per Android Gradle Plugin 9 e un requisito minimo degli strumenti più elevato. Node.js 22.13+, Kotlin 2.0+ con la versione 2.2 inclusa e compileSdk portato a 37.

Se la vostra app è ancora su una versione precedente, questo non è un aggiornamento di versione di routine. Il team di React Native lo definisce il passo più grande verso la versione 1.0 degli ultimi tempi, e l'elenco delle funzionalità rimosse lo conferma.

Cosa cambia concretamente la Strict API

Fino ad ora, i tipi TypeScript di React Native erano mantenuti manualmente separatamente dal codice sorgente, e di conseguenza divergevano. I tipi promettevano cose che il codice non faceva, e i percorsi interni dei file trapelevano come se fossero pubblici. La Strict API risolve questo problema generando i tipi direttamente dal codice sorgente e limitando il contratto pubblico a ciò che react-native esporta alla radice.

La conseguenza pratica: le importazioni profonde come react-native/Libraries/... sono ora errori di tipo. Se avete mai utilizzato un percorso interno per ottenere qualcosa che non era ufficialmente esportato, quel codice non supererà più il controllo dei tipi. Cambiano anche i tipi ref. I componenti built-in sono ora tipizzati come funzioni, non classi, quindi useRef<View>() non funziona più. Ogni componente ottiene invece un tipo di istanza dedicato, come ViewInstance e TextInputInstance.

Esiste una via d'uscita temporanea. Potete tornare ai vecchi tipi manuali con customConditions: ["react-native-legacy-deep-imports"] nel vostro tsconfig.json. Consideratelo come tempo di respiro, non come destinazione finale. Il team ha dichiarato che la possibilità di opt-out sarà rimossa in una futura release, quindi la migrazione arriverà che la facciate ora o in seguito.

Un dettaglio che vi risparmierà un pomeriggio difficile: la Strict API influisce solo sull'analisi TypeScript del vostro progetto, nell'ambito del vostro tsconfig.json, e richiede che skipLibCheck sia attivo. La configurazione TypeScript di React Native lo abilita per impostazione predefinita. Se avete disabilitato skipLibCheck, riattivatelo prima di iniziare, altrimenti sarete sommersi da errori provenienti da file .d.ts di terze parti che non potete correggere.

Le rimozioni che colpiscono le app mature

La Strict API fa notizia, ma sono le silenziose rimozioni a rompere le codebase più datate. Alcune di quelle che cercheremmo per prime:

• InteractionManager è stato rimosso. Spostate il lavoro differito su requestIdleCallback.
• I TurboModules sono ora sempre attivi. Il flag di funzionalità useTurboModules è stato rimosso, quindi se lo stavate ancora alternando, quel codice va eliminato.
• useColorScheme() restituisce ColorSchemeName | null e non restituisce più 'unspecified'. Qualsiasi ramo che gestisce quella stringa è ora inutilizzato.
• Le prop deprecate di StatusBar (backgroundColor, translucent) e i loro setter sono stati rimossi, insieme alla prop animated di Modal e al supporto booleano di keyboardShouldPersistTaps per ScrollView.

Nessuno di questi è difficile di per sé. Il problema è trovarli tutti in un'app di grandi dimensioni prima che emergano a runtime o in un CI fallito.

SwiftPM e AGP 9: reali, ma non urgenti

Le modifiche sul lato nativo sono quelle che ci interessano di più nel nostro lavoro mobile. Il supporto di Swift Package Manager significa che potete finalmente costruire un progetto iOS senza Ruby, Bundler o CocoaPods nel processo. È sperimentale e opt-in, CocoaPods rimane il percorso predefinito e supportato, e consuma gli stessi XCFrameworks precompilati che React Native già distribuisce. Nei nostri progetti iOS nativi, la toolchain CocoaPods è stata una fonte affidabile di fallimenti CI del tipo «funziona sulla mia macchina», quindi un percorso che usa solo Xcode è genuinamente benvenuto. Non sposteremmo ancora una build di produzione su di esso, ma vale la pena attivarlo su un branch per vedere come gestisce il vostro grafo delle dipendenze.

Su Android, la 0.87 è la prima release a supportare AGP 9. La raccomandazione del team stesso è significativa: escludete per ora il Kotlin integrato e il nuovo DSL di AGP 9 impostando android.builtInKotlin=false e android.newDsl=false in gradle.properties. Questi opt-out sono destinati a sparire intorno ad AGP 10. In altre parole, Google e il team di React Native stanno ancora stabilizzando questo, e il percorso sancito è deliberatamente conservativo. Dal nostro lavoro con Kotlin e Jetpack Compose, abbiamo imparato a rispettare quel tipo di indicazioni. Adottare un plugin Gradle principale la settimana in cui viene rilasciato, con le impostazioni predefinite che gli stessi maintainer vi dicono di disabilitare, è il modo in cui si perde uno sprint a causa di errori di build.

L'ordine di aggiornamento che useremmo

Ecco la sequenza che eseguiremmo per un'app reale, partendo dal rischio minore:

1. Aggiornate la toolchain prima di toccare React Native. Passate a Node.js 22.13+, Kotlin 2.0+ e compileSdk 37 come passi separati e verificabili. Se qualcosa si rompe qui, volete sapere che è stata la toolchain, non il framework.
2. Aggiornate alla 0.87 con l'opt-out per i tipi legacy ancora attivo. Questo isola le rimozioni a runtime, le modifiche a InteractionManager e StatusBar, dalla migrazione dei tipi, in modo da eseguire il debug di una cosa alla volta.
3. Attivate la Strict API per ultima. Rimuovete l'opt-out, eseguite tsc e affrontate gli errori di importazione profonda e di tipo ref come passaggio dedicato. Questo è il cambiamento che con più probabilità toccherà il codice condiviso e le librerie di terze parti, quindi dategli una PR dedicata.

La parte pratica che potete fare oggi, prima di qualsiasi aggiornamento: eseguite una ricerca a livello di progetto per react-native/Libraries/ e ogni importazione profonda negli internals di React Native. Quel singolo grep vi dice quanto lavoro sulla Strict API dovete affrontare realmente. Se il conteggio è zero, questo aggiornamento è per lo più meccanico. Se è nell'ordine delle centinaia, avete una conversazione di pianificazione, non un aggiornamento del venerdì pomeriggio.

C'è una lezione più ampia qui che vediamo sia nel web che nel mobile. Quando costruiamo app cloud-native per clienti enterprise, i framework che sopravvivono sono quelli che alla fine tracciano un confine netto intorno alla loro API pubblica e lo mantengono. React Native ha derivato per anni perché i tipi e il codice sorgente erano due cose diverse mantenute manualmente. Questa release è la correzione. Fa male una volta, e poi i refactoring interni smettono di essere i vostri breaking change. È un compromesso che vale la pena fare, e i team enterprise svizzeri con cui lavoriamo, dove un breaking change non pianificato può far saltare l'approvazione di conformità, preferiranno sempre un'API prevedibile a una comoda. Potete vedere il tipo di lavoro mobile e di sviluppo che facciamo su progetti nativi e cross-platform.

Se un audit del tipo «quali delle nostre importazioni stanno per diventare errori di tipo» vi suona familiare, parliamone. Aiutiamo i team a pianificare aggiornamenti del framework che non si trasformano in yak-shave di un mese.