Expo adopte le TextDecoder de Hermes

Le décodeur appartient désormais au moteur

La PR Expo #50853 (nouvelle fenêtre), fusionnée le 1er octobre, supprime le décodeur UTF-8 fourni par Expo au profit de celui de Hermes dans React Native 0.88. La motivation est concrète : le remplacement par un polyfill limité à UTF-8 pouvait casser des consommateurs d’autres encodages, notamment dans des chemins PDF ou image.

Le décodeur Hermes prend en charge UTF-8, UTF-16 et des encodages historiques à un octet tels que Windows-1252. La PR supprime également l’enregistrement global de l’ancienne implémentation. Un runtime JavaScript personnalisé doit fournir TextDecoder avant l’initialisation d’Expo.

Un changement observable dans les fichiers importés

Une app qui ne manipule que du JSON UTF-8 peut ne voir aucune différence. Un import de document ancien, un outil de génération PDF ou une réponse binaire décodée par une bibliothèque peut, lui, emprunter ce chemin sans que le code métier appelle directement TextDecoder.

La distinction entre octets et texte est donc le point à conserver dans l’architecture. Le choix d’encodage devrait provenir du format lu ou de ses métadonnées. Transformer arbitrairement tous les fichiers en UTF-8 au premier point d’entrée risque de perdre l’information nécessaire pour les interpréter correctement.

Pour une équipe qui fournit son propre runtime, cette modification est aussi une dépendance de démarrage : le global doit exister au moment où Expo initialise ses modules. Ajouter un polyfill tard dans un écran ne corrigerait pas cette frontière. La référence de migration pertinente est l’ordre d’initialisation du runtime, puis les formats de fichiers réellement traités par l’application.