React Native : comment une simple mise à jour fait tout s'écrouler

#reactnative #mobile #webdev #programming

En tant que développeuse full-stack dans une entreprise qui jongle avec plusieurs produits, je travaille principalement sur des applications web. Le mobile n'est pas notre spécialité, et comme souvent, nous faisons les montées de version au dernier moment. C'est dans ce contexe que replonge dans les profondeurs de React Native.
Première appréhension, est ce que le projet rebuild ? Là, j'ai déjà une petite victoire, celui qui a déjà fait du mobile connaît cette joie de voir passer son npm run android et l'application se lance, mais tout ce n'est pas passé comme prévu.
Je souhaite partager avec vous les difficultés rencontrées pendant une semaine dans cet article.

Chronologie : une semaine mouvementée avec React native

Jour 1. La migration Android SDK - L'optimisme du début

Mission : passer d'Android SDK33 à 35 pour supporter Android 15
La première étape semblait simple sur le papier. J'ai attaqué méthodiquement :

Modification du android/build.gradle pour basculer compileSdkVersion et targetSdkVersion vers 35
Mise à jour buildToolsVersion vers "35.0.0"
Upgrade Android Gradle Plugin : 8.2.0 → 8.6.0 (première alerte rouge que j'aurais du voir venir)
Ajout de la propriété magique android.suppressUnsupportedCompileSdk=35 dans gradle.properties

verdict : Build Android réussi ! Je pensais naïvement que ce serait aussi simple que ça.

2. Jour 2 : le château de cartes des dépendances npm commence à vaciller

C'est là que la réalité m'a rattrapé. Les conflits de dépendances ont commencé leur danse infernale :

Voici un exemple d'un de mes nombreux problèmes de la journée :
React 18.2.0 ne voulait plus parler à react-intl@4.5.0 qui réclamait demande React ^16.3.0.

Ma descente aux enfers* :

Premier réflexe : le classique rm -rf node_modules suivi d'une réinstallation
Échec. Tentative avec npm install --legay-peer-deps pour forcer la roue
Miracle : 2266 packages installés ! (avec seulement 62 vulnérabilités comme cadeau bonus)

Jour 3 : Gradle, un vieil ennemi oublié

Au moment où je pensais avoir dompté npm, Gradle s'est rappelé à moi :

" Error resolving plugin [id : 'com.facebook.react.settings'] node_modules/@react-native/gradle-plugin' does not exist"

Le diagnostic : notre React Native 0.71.8 ne connaissant pas ce plugin qui n'existe qu'à partir de la version 0.72+.
A ce moment là j'ai même pensé recommencer l'application de zéro entre les soucis de dépendances et de build, j'étais à deux doigts de faire lancer un npx create-expo-app@latest

La méthodologie : réécriture complète du settings.gradle en remplaçant les références futuristes par la vielle méthode @react-native-community/cli-platform-android

Jour 4 : Jitsi - Le boss final

C'est ici que j'ai compris l'ampleur du désastre :
Oui, Jitsi (Logiciel de visioconférence open source gratuit pour le web et les appareils mobiles) sort des versions régulières, la dernière 11.4.0. Mais entre la théorie et la pratique, il y a un gouffre, faire tourner ces versions avec un projet React native qui a été initié il y a 5 ans.

" Could not resolve com.android.tolls.build:gradle:3.5.3"

La révélation : la version implémentée dans mon projet du SDK Jitsi vivait encore en 2019 avec Android Gradle Plugin 3.5.3, complètement incompatible avec notre stack moderne (SDK35+AGP 8.6.0).
Les repositories Maven refusaient même de répondre à des requêtes aussi lointaines...

L'espoir : du coup, j'ai installé la dernière version du SDK Jitsi et j'ai été heureuse, car un moment, j'avais même réussi à faire monter la version de React native en 0.77.3, mais là retour de la boucle infernale des dépendaces...

Issues :
Après de l'errance sur le web, je tombe sur l'issue qui disait https://github.com/jitsi/jitsi-meet/issues/14912 ne supportait pas les versions React natives supérieures à 0.73.

Jour 5 : les erreurs runtine

Après avoir réussi à compiler (petit miracle même si cela ne marchait pas !), l'application a décidé de me gratifier d'un magnifique :
"Failed to get room and jwt using code : 10208310 [Error: Request failed with status code 500]"
L'origine : une fonction appelée dans le front ne marchait plus, ce n’était même pas lié à la migration. Le backend avait ses propres problèmes...

Cette semaine m'a vraiment fait prendre conscience à quel point c'est compliqué de garder une application mobile à jour, surtout quand ce n'est pas notre cœur de métier. On pense naïvement qu'on va juste mettre à jour une petite dépendance, mais en fait, c'est toute une cascade de changements qui s'enchaîne...

Le plus dur, c'est qu'on touche à cette application de temps en temps seulement. Du coup, à chaque fois qu'on y revient, on se retrouve avec des mois de retard à rattraper d'un coup.

La prochaine fois qu'on me dira " on a juste besoin de mettre à jour le SDK pour publier", je saurai que c'est le début d'une nouvelle aventure, car avec React native il n'y a pas de petites mises à jour juste de grandes batailles... Où je poserai mes vacances à ce moment-là ...

Image de couverture générée à partir d'une IA