Metro

Le point d’entrée est metro.config.js (ou metro.config.mts depuis Metro 0.87, embarqué à partir de React Native 0.87), qui étend getDefaultConfig de expo/metro-config ou de @react-native/metro-config. Un projet qui ne part pas de ce défaut, ou qui copie une config d’il y a trois ans, perd les réglages ajoutés depuis : résolution des exports de package, support des monorepos, assets SVG, etc. La règle que j’applique : la config custom doit tenir en quelques lignes et chaque ligne doit avoir une raison écrite en commentaire.

Les problèmes de résolution sont les plus fréquents. Un module introuvable alors qu’il est bien dans node_modules vient souvent du cache (npx expo start --clear), d’une version dupliquée dans un monorepo, ou d’un champ exports de package que Metro interprète différemment de Node. Les fichiers .native.ts et .web.ts sont la bonne façon de séparer du code par plateforme ; un Platform.OS qui conditionne un require pose des problèmes de tree shaking à l’export web.

Metro lui-même a beaucoup bougé : résolution annoncée 15 fois plus rapide avec React Native 0.76, génération des source maps deux fois plus rapide et moitié moins de mémoire avec Metro 0.87. Si le dev server d’un projet est lent, la première chose à vérifier est la version de Metro réellement installée (npm ls metro), pas la config.