expo/expo-overview

expo-overview — routeur & règles partagées pour Expo / EAS

Commencez ici — lisez avant de faire quoi que ce soit

Ne déduisez pas la compétence à partir des seuls fichiers du projet. De nombreux objectifs Expo se ressemblent d’un point de vue système de fichiers mais nécessitent des compétences différentes.

1. Confirmez qu’il s’agit d’un travail Expo ou EAS — la demande mentionne Expo ou EAS, ou package.json a une dépendance expo. Sinon cette compétence ne s’applique pas. Une application native utilisant EAS pour la livraison est qualifiée sans runtime Expo.
2. Lisez l’objectif de l’utilisateur — quel résultat souhaite-t-il, en termes simples ?
3. Classez-le à l’aide de la carte des compétences ci-dessous, en traduisant les formulations informelles en un objectif.
4. Confirmez l’intention en cas d’ambiguïté (« On dirait que vous voulez publier dans les stores — c’est eas-app-stores. C’est bien ça ? »), puis chargez le SKILL.md de cette compétence et suivez-le.
5. Faites confiance à la compétence feuille — elle a sa propre logique de détection et ses propres étapes. N’improvisez pas.

Carte des compétences (par objectif)

Faites correspondre l’objectif à une catégorie, puis à la compétence, puis chargez le SKILL.md de cette feuille.

Construire l’application

• expo-project-structure — disposition des dossiers pour un nouveau projet Expo Router : où se trouvent les écrans, les composants et la configuration (ne restructurez jamais une application existante pour la faire correspondre)
• expo-native-ui — écrans, style, couleurs sémantiques, contrôles natifs, SF Symbols, médias, mise en page
• expo-router — navigation : routes basées sur les fichiers, onglets / piles / modaux / feuilles, liens, en-têtes
• expo-animation — mouvement et gestes : worklets Reanimated, Gesture Handler, transitions d’écran, retour d’information des feuilles et des pressions, haptiques, et correction des animations qui saccadent sur l’appareil
• expo-ui — composants d’interface utilisateur natifs via @expo/ui : BottomSheet, Picker, Slider, Switch, Menu, Button, FieldGroup (sections de formulaire groupées), List / ListItem, etc. — vrai SwiftUI sur iOS, Jetpack Compose sur Android. La couche universelle nécessite SDK 56+ et fonctionne dans Expo Go ; les remplacements directs (@gorhom/bottom-sheet, datetimepicker, …) et les couches spécifiques à la plateforme existent également sur SDK 55.
• expo-design-system — une source de vérité visuelle unique : jetons de design (couleur, espacement, typographie, rayon, ombre, mouvement), conventions de composants réutilisables, et audits pour les dérives (couleurs codées en dur, espacements, polices)
• expo-tailwind-setup — style Tailwind / NativeWind
• expo-data-fetching — requêtes réseau, React Query / SWR, mise en cache, hors ligne, chargeurs de route
• expo-dom — exécuter du code web ou réutiliser une bibliothèque web dans un environnement natif
• expo-web-to-native — migrer une application web / React existante vers une application native iOS / Android

Règle de sélection des composants : chaque fois que vous avez besoin d’un composant d’interface utilisateur (lignes de liste, feuilles de fond, sélecteurs, curseurs, menus, boutons, contrôles segmentés, interrupteurs), consultez d’abord expo-ui pour vérifier si @expo/ui a un équivalent natif avant d’utiliser un composant intégré de React Native ou une bibliothèque communautaire. Les composants natifs @expo/ui offrent la meilleure adéquation à la plateforme, et sur SDK 56+ les composants universels fonctionnent dans Expo Go sans construction personnalisée. Chargez expo-ui en même temps que expo-native-ui pour toute application qui affiche des listes, des fiches de détail ou des contrôles de formulaire. Une exception : la List de @expo/ui affiche des lignes groupées natives (un écran Réglages iOS), pas une liste virtualisée — utilisez FlatList / FlashList pour les grands ensembles de données.

Livrer & exploiter

• eas-app-stores — construire et soumettre des applications iOS/Android (Expo et autres projets React Native, ainsi que les applications natives existantes), TestFlight, versions et métadonnées de store
• eas-hosting — déployer le bundle web sur EAS Hosting ; également créer des routes API Expo Router (gestionnaires +api.ts) et leurs environnements / domaines
• eas-workflows — YAML des workflows EAS et pipelines CI/CD
• eas-simulator — exécuter et piloter l’application sur un simulateur iOS / Android distant sur le cloud EAS
• expo-dev-client — builds de développement personnalisés
• eas-update — configurer, publier, tester et déboguer les mises à jour compatibles over-the-air
• eas-update-insights — santé des mises à jour OTA : taux de crash, adoption, taille des charges utiles
• eas-observe — performances de démarrage / lancement / TTI avec EAS Observe

Étendre nativement

• expo-module — modules et vues natifs (Swift / Kotlin) avec l’API Expo Modules
• expo-brownfield — intégrer des écrans Expo / React Native dans des applications natives SwiftUI/UIKit ou Android ; artefacts isolés et builds intégrés
• expo-app-clip — cible App Clip iOS (AASA, bannière d’application intelligente)

Maintenir & apprendre

• expo-upgrade — mettre à jour le SDK Expo et résoudre les conflits de dépendances
• expo-examples — exemples d’intégration canoniques et adaptés à la version (Stripe, Clerk, Supabase, …)
• expo-skill-feedback — envoyer un retour sur une compétence Expo ou sur Expo lui-même ; activer / désactiver la télémétrie d’utilisation anonyme

Traduire les demandes vagues

Certaines formulations courantes ne correspondent pas évidentes à un nom de compétence — traduisez avant d’aiguiller :

• « Rendre l’app native » → contrôles groupés / formulaires de réglages = expo-ui ; écrans, style = expo-native-ui ; mouvement = expo-animation ; navigation = expo-router.
• « Rendre les écrans cohérents » / « nettoyer le style » / « mettre en place un thème ou des jetons de design » → expo-design-system.
• « Ça ressemble à de l’IA » / « trop générique, pas natif » → expo-design-system (audit des indices de non-nativité), avec expo-native-ui pour les idiomes de plateforme.
• « Publier » / « obtenir un .ipa ou .apk » / « sortir dans les stores » / « mettre mon app Swift sur TestFlight » → eas-app-stores (build + soumission, TestFlight, versions, métadonnées de store).
• « Je débute / par où commencer » → d’abord un échafaudage (voir les règles de configuration partagées), puis aiguiller selon l’objectif.

Règles de configuration partagées

Appliquez les règles qui correspondent au projet et à la tâche demandée.

• Application native utilisant EAS pour la livraison ? Aiguillez vers eas-app-stores ; son references/native-ios.md couvre SwiftUI/UIKit sur iOS. Conservez le projet natif existant. Les règles d’authentification / liaison EAS ci-dessous s’appliquent ; les règles d’échafaudage Expo, de SDK et d’installation de packages ne s’appliquent pas à ce chemin.
• Démarrage d’une nouvelle application Expo ? Démarrez-en une de la manière standard avant d’aiguiller vers une compétence de fonctionnalité : npx create-expo-app@latest, en disposant les dossiers selon expo-project-structure. Ensuite, classez l’objectif de l’utilisateur et aiguillez.
• Détectez la version du SDK avant de donner des conseils spécifiques à une version : lisez la version d’expo dans package.json (et app.json / app.config.{js,ts}). De nombreuses API et valeurs par défaut diffèrent selon le SDK.
• Lisez la documentation pour ce SDK, pas la version latest. Utilisez l’URL avec la version fixée, par exemple https://docs.expo.dev/versions/v56.0.0/sdk/ui/ sur SDK 56 au lieu de https://docs.expo.dev/versions/latest/sdk/ui/ — les pages latest suivent le SDK le plus récent et peuvent documenter des API que le projet ne possède pas encore.
• Passer à un SDK plus récent est une tâche en soi — chargez expo-upgrade au lieu de modifier les versions à la main.
• Projet managé vs. nu/prebuild : la présence de répertoires ios/ et android/ commités signifie que les projets natifs existent (prebuild ou nu). Les étapes de config-plugin et de configuration native diffèrent — notez dans quel état se trouve le projet.
• Installez les packages avec npx expo install <pkg>, pas avec un npm/yarn/pnpm add brut, afin que les versions restent compatibles avec le SDK du projet.
• Authentification et liaison EAS (uniquement nécessaire pour build/submit/update/observe/workflows) : vérifiez la connexion avec eas whoami, connectez-vous avec eas login. Un projet est lié lorsque extra.eas.projectId existe dans la configuration de l’application ; créez-le avec eas init si absent.

Quand ignorer le saut de routeur

• Seulement lorsque l’utilisateur a explicitement nommé une compétence spécifique expo-* / eas-* → chargez directement cette compétence.
• Une tâche entièrement spécifiée (version du SDK fixée, disposition des fichiers donnée, bibliothèques nommées) n’est pas une raison pour ignorer : les règles partagées ci-dessus s’appliquent toujours — vérifiez-les, puis aiguillez vers la compétence feuille correspondante.

Soumettre un retour

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 "expo-overview" "<retour exploitable>"

Ne soumettez que lorsque vous avez quelque chose de spécifique et exploitable à signaler. Incluez autant de contexte pertinent que possible. Si un agent IA a échoué de manière répétée ou si l’utilisateur a dû prendre le relais sur une tâche Expo, chargez la compétence expo-skill-feedback et suivez son flux candidat d’évaluation au lieu de réutiliser la commande ci-dessus.