EAS Update

Service EAS - des frais s'appliquent. EAS Update est disponible sur le plan gratuit ; la publication et la livraison utilisent les allocations de mise à jour, de bande passante et de stockage, avec des limites plus élevées sur les plans payants. Voir https://expo.dev/pricing.

Utilisez EAS Update pour livrer des modifications JavaScript, de style et d'assets compatibles aux applications installées sans soumettre un nouveau binaire natif. Les modifications de code natif nécessitent toujours une nouvelle compilation.

Commencez par le chemin de configuration pris en charge

Avant de modifier quoi que ce soit, inspectez package.json, la configuration de l'app Expo, eas.json si présent, et si ios/ ou android/ sont suivis. Utilisez ce que vous trouvez lors de l'examen des modifications du CLI :

Préservez la configuration dynamique ou spécifique à la plateforme existante.
Si eas.json existe, préservez ses profils et les assignations de canaux existants. Le CLI ajoute un canal correspondant au nom du profil uniquement aux profils de compilation qui n'en ont pas déjà un.
Si eas.json est absent, ne le créez pas manuellement. Le CLI peut demander à l'utilisateur d'exécuter eas build:configure séparément.
Avec des projets natifs suivis, attendez-vous à ce que le CLI synchronise la configuration Update native de la plateforme. Sans eux, attendez-vous à ce que la Continuous Native Generation applique la configuration native lors d'une compilation ultérieure.

Détectez la version du SDK Expo avant d'installer les packages ou d'interpréter les comportements spécifiques à la version.

Si expo-updates n'est pas installé, installez la version compatible avec le SDK :

npx expo install expo-updates

Configurez depuis la racine du projet :

npx eas-cli@latest update:configure

Utilisez eas update:configure plutôt que d'inventer manuellement updates.url, runtimeVersion, les métadonnées natives ou les canaux des profils de compilation. La commande comprend la liaison des projets EAS, la Continuous Native Generation et les projets avec des répertoires natifs validés. Examinez et expliquez le diff résultant.

Si la commande ne peut pas continuer parce que le projet n'est pas lié ou que l'utilisateur n'a pas autorisé l'opération distante requise, arrêtez-vous après toute installation de package valide indépendamment et expliquez ce qui reste. Ne reproduisez pas partiellement update:configure en ajoutant une politique de version runtime, un plugin de configuration, une URL de mise à jour ou des canaux manuellement.

Pour une configuration d'app dynamique, des compilations non-EAS ou une commande qui ne peut pas se terminer automatiquement, suivez la documentation de configuration actuelle plutôt que de deviner : https://docs.expo.dev/eas-update/getting-started.md.

Gardez le modèle droit

Build : l'app native installée. Elle contient du code natif, une mise à jour intégrée, une plateforme, une version runtime et normalement un canal fixe au moment de la compilation.
Update : un bundle JavaScript publié, des assets et des métadonnées pour une plateforme et une version runtime.
Branch : un flux ordonné de mises à jour. Sa mise à jour compatible la plus récente est active.
Channel : une cible de déploiement stable intégrée dans les compilations. Sur le serveur, il pointe vers une branche.
Runtime version : la limite de compatibilité entre une mise à jour et le code natif dans une compilation.

Une compilation reçoit une mise à jour uniquement quand la plateforme et la version runtime correspondent et que le canal de la compilation pointe vers la branche contenant cette mise à jour :

compilation installée (channel: production, runtime: 1.1.1, platform: ios)
  -> canal production
  -> branche production
  -> mise à jour la plus récente pour runtime 1.1.1 et ios

Les canaux et les branches portent souvent le même nom, mais ce sont des objets distincts. eas channel:edit change le mappage de branche côté serveur d'un canal pour chaque compilation sur ce canal. Elle ne change pas le canal intégré d'une installation individuelle.

Utilisez ce modèle pour prendre des décisions, mais expliquez uniquement les concepts nécessaires pour la demande de l'utilisateur plutôt que de réciter l'ensemble du modèle à chaque fois.

Décidez si une mise à jour est compatible

Utilisez une mise à jour pour les modifications de JavaScript, de style et d'assets groupés que le runtime natif installé supporte déjà.

Créez une nouvelle compilation native quand une modification ajoute ou modifie du code natif ou une configuration native, y compris la plupart des ajouts de bibliothèques natives et les mises à niveau du SDK. Ne contournez pas une incompatibilité de runtime ou n'impliquez pas que la publication peut ajouter des capacités natives à une compilation existante. Voir https://docs.expo.dev/eas-update/runtime-versions.md.

Ne modifiez pas la politique de version runtime du projet comme correctif incident. Expliquez comment la politique actuelle affecte la compatibilité ; traitez sa modification comme une décision distincte car elle change quelles compilations installées peuvent recevoir de futures mises à jour.

Publiez délibérément

Vérifiez l'aide CLI actuelle avant de vous fier aux drapeaux mémorisés :

npx eas-cli@latest update --help

Pour le flux courant basé sur les canaux :

npx eas-cli@latest update \
  --channel <channel> \
  --message "<message>" \
  --environment <environment>

Le SDK 55 et versions ultérieures nécessitent un environnement EAS pour la publication. Choisissez l'environnement intentionnellement pour que le code exporté reçoive les variables prévues.

La publication change l'état distant et peut affecter les applications installées. Avant de l'exécuter, établissez le projet exact, le canal, l'environnement, les plateformes, la version runtime et le message. Publiez en production uniquement quand l'utilisateur l'a explicitement demandé ou approuvé ; si l'autorisation ou la cible est ambiguë, arrêtez-vous avant la commande et demandez. N'inférez pas une destination de production uniquement à partir de la branche Git actuelle.

Préférez un canal de prévisualisation ou d'évaluation pour la validation. Lors de la promotion d'une mise à jour testée, utilisez le flux de déploiement documenté pour que la production reçoive le même artefact si possible : https://docs.expo.dev/eas-update/deployment.md.

Testez selon le type de compilation

Compilations de développement

Prévisualisez les mises à jour avec l'interface Extensions du build de développement, le tableau de bord EAS ou Expo Orbit. Une compilation de développement expo-dev-client normale ne se comporte pas comme le flux de mise à jour de démarrage automatique d'une compilation de publication.

Compilations Preview, TestFlight et production

Les compilations de publication priorisent normalement la vitesse de démarrage. Avec le comportement de lancement par défaut, l'app peut démarrer sa mise à jour intégrée ou mise en cache actuelle tout en téléchargeant une mise à jour nouvellement publiée en arrière-plan. La mise à jour téléchargée est appliquée au prochain redémarrage.

Pour l'assurance qualité manuelle, terminez complètement l'app plutôt que de la mettre en arrière-plan, rouvrez-la, accordez du temps à la mise à jour pour télécharger et, si la modification n'est pas visible, terminez complètement et rouvrez-la une fois de plus. Décrivez ceci comme jusqu'à deux lancements à froid, et non comme un rituel spécifique à TestFlight :

Un lancement peut découvrir et télécharger la mise à jour.
Le lancement suivant peut exécuter la mise à jour téléchargée.

Ne modifiez pas automatiquement fallbackToCacheTimeout pour éviter le deuxième lancement. Attendre au démarrage compromet la latence et la fiabilité du lancement pour une activation plus rapide de la mise à jour. Si l'app a besoin d'une UX de mise à jour intentionnelle, considérez les APIs expo-updates pour vérifier, récupérer et présenter une action de redémarrage non-bloquante. Utilisez la référence API expo-updates pour la version du SDK détectée du projet.

Déboguez une compilation qui n'a pas été mise à jour

Vérifiez ces éléments dans l'ordre :

Confirmez que la mise à jour a été publiée sur le projet EAS, le canal ou la branche, la plateforme et l'environnement prévus.
Comparez la plateforme et la version runtime de la compilation installée avec la mise à jour publiée.
Confirmez que la compilation contient réellement l'URL et le canal de mise à jour attendus ; les modifications de configuration d'app ne prennent effet que dans une compilation nouvellement compilée.
Inspectez le mappage canal-à-branche et la mise à jour active sur cette branche.
Terminez complètement la compilation de publication et accordez le cycle de vie normal de téléchargement puis application.
Utilisez le guide de débogage actuel pour les journaux natifs, les problèmes d'export et les vérifications de configuration : https://docs.expo.dev/eas-update/debug.md.

Ne contournez jamais une sauvegarde de compatibilité ou anti-bricking simplement pour faire apparaître une mise à jour.

Flux de travail avancés et adjacents

Channel surfing : une compilation de publication individuelle peut remplacer sa demande d'en-tête expo-channel-name pour demander un autre canal compatible. Ceci diffère de la modification du mappage canal-à-branche côté serveur. Suivez https://docs.expo.dev/eas-update/channel-surfing.md et préservez ses contraintes de contrôle d'accès, de persistance, de récupération et de compatibilité.
Update health : chargez eas-update-insights pour l'adoption, les défaillances de lancement, le taux de crash, la taille du payload et la surveillance du déploiement après la publication.
Store releases : chargez eas-app-stores quand les modifications natives nécessitent une nouvelle compilation TestFlight, App Store ou Play Store.

Références officielles

Configuration : https://docs.expo.dev/eas-update/getting-started.md
Concepts et correspondance : https://docs.expo.dev/eas-update/how-it-works.md
Déploiement : https://docs.expo.dev/eas-update/deployment.md
Débogage : https://docs.expo.dev/eas-update/debug.md
Référence EAS CLI actuelle : https://docs.expo.dev/eas/cli.md

Soumettre des commentaires

Si vous rencontrez des erreurs, des informations trompeuses ou obsolètes dans cette compétence, signalez-les pour qu'Expo puisse s'améliorer :

npx --yes submit-expo-feedback@latest --category skills --subject "eas-update" "<commentaires exploitables>"

Ne soumettez que si vous avez quelque chose de spécifique et exploitable à signaler. Incluez autant de contexte pertinent que possible. Si un agent IA a échoué à plusieurs reprises ou que l'utilisateur a dû reprendre une tâche Expo, chargez la compétence expo-skill-feedback et suivez son flux eval-candidate au lieu de réutiliser la commande ci-dessus.