Chapitre 2.1 — Node, pnpm & create-expo-app

Où on en est : début de l’installation. Ce chapitre pose la toolchain JS (que vous avez sans doute déjà) et crée un premier projet jetable pour en disséquer l’anatomie.

⏱️ TL;DR — Node LTS ≥ 20 + pnpm, puis pnpm create expo-app@latest : le template par défaut arrive en TypeScript avec Expo Router préconfiguré. On lance npx expo start, et on dissèque chaque fichier généré : app/, app.json, assets/, tsconfig.json. Rien d’exotique pour vous — c’est un projet Node avec deux fichiers de config en plus.

🎯 Objectifs

• Vérifier/installer Node LTS et pnpm sur Windows.
• Créer un projet Expo et comprendre chaque fichier généré.
• Savoir ce que fait npx expo start (et ce qu’il ne fait pas).
• Connaître la place de package.json vs app.json.

Node & pnpm

Vous les avez probablement déjà. Vérification :

# PowerShell
node -v    # ≥ 20 (LTS). Sinon : winget install OpenJS.NodeJS.LTS
pnpm -v    # ≥ 9. Sinon : npm install -g pnpm

💡 Pour un dev Next.js — pnpm fonctionne parfaitement avec Expo en 2026 (l’époque des soucis de symlinks avec Metro est révolue). On l’utilise dans tout le cours, comme dans vos projets web. Seule nuance : pour les libs natives, on passera par npx expo install (chapitre 1.4) — qui utilise votre gestionnaire détecté, donc pnpm, sous le capot.

Créer le premier projet

Créons un projet jetable (Drill officiel = chapitre 2.5) :

cd C:\Users\Alexl\Desktop
pnpm create expo-app@latest hello-rn
cd hello-rn

Le template par défaut (SDK 57) fournit : TypeScript configuré, Expo Router installé avec un exemple à deux onglets, ESLint, et les assets de base. Pas de question posée, pas de choix à faire — c’est le « golden path » d’Expo.

Premier lancement :

npx expo start

Metro démarre et affiche un QR code dans le terminal. Laissez-le tourner — on le scanne au chapitre suivant. Notez déjà : expo start ne compile rien de natif. Il sert votre JS, c’est tout (chapitre 1.3 : c’est Expo Go qui apporte le natif en phase d’apprentissage).

Anatomie du projet généré

hello-rn/
├── app/                  ← vos écrans (Expo Router : 1 fichier = 1 route)
│   ├── (tabs)/
│   │   ├── index.tsx     ← l'onglet d'accueil (route /)
│   │   ├── explore.tsx   ← second onglet (route /explore)
│   │   └── _layout.tsx   ← le layout des tabs
│   └── _layout.tsx       ← layout racine (≈ app/layout.tsx de Next.js)
├── assets/               ← images, polices (icône, splash…)
├── components/           ← composants réutilisables du template
├── constants/            ← couleurs, etc.
├── app.json              ← ⭐ la config de L'APP (nom, icône, permissions…)
├── package.json          ← deps + scripts (votre monde habituel)
├── tsconfig.json         ← étend expo/tsconfig.base, strict
└── expo-env.d.ts         ← types générés (routes typées)

Trois observations importantes :

1. app/ vous est familier. Un fichier = une route, _layout.tsx = layout imbriqué. Expo Router est délibérément calqué sur App Router — la Partie 5 détaille les différences (pas de Server Components : tout est client, on est dans une app embarquée).

2. app.json est nouveau. C’est la carte d’identité de l’app — méconnaissez-le et rien ne se builde correctement plus tard :

// app.json (extrait du template)
{
  "expo": {
    "name": "hello-rn",           // nom affiché sous l'icône
    "slug": "hello-rn",           // identifiant Expo (URLs EAS)
    "scheme": "hellorn",          // deep links (Partie 5)
    "userInterfaceStyle": "automatic",  // suit le dark mode système
    "newArchEnabled": true,       // New Architecture (défaut)
    "android": {
      "adaptiveIcon": { "foregroundImage": "./assets/images/adaptive-icon.png" }
      // plus tard : "package": "com.alex.drill" (Partie 12)
    },
    "plugins": ["expo-router"]    // config plugins (chapitre 1.3, Partie 11)
  }
}

Tout ce qui, sur le web, serait des métadonnées de déploiement (nom, icônes, permissions, schéma d’URL) vit ici. Les config plugins listés modifient les projets natifs au prebuild. En Partie 11 on le convertira en app.config.ts (version TypeScript, dynamique).

3. Pas de dossier android/. Rappel du chapitre 1.3 : il n’existe pas tant qu’on n’en a pas besoin — CNG le générera. Votre repo ne contient que du JS/TS et de la config.

Les scripts du quotidien

// package.json (extrait)
{
  "scripts": {
    "start": "expo start",
    "android": "expo run:android",   // build natif local + lance (Partie 11)
    "lint": "expo lint"
  }
}

⚠️ Piège — Le cache de Metro est la première cause de comportements fantômes (« j’ai supprimé ce fichier et il vit encore »). Réflexe pavlovien à installer dès aujourd’hui : au moindre doute, npx expo start -c. Vous venez d’économiser des heures.

✏️ Exercices

1. Créez le projet hello-rn, lancez npx expo start, et identifiez dans la sortie du terminal : l’URL de Metro et le QR code. Que se passe-t-il si vous ouvrez l’URL dans Chrome ?

2. Dans app.json, changez "name" en "Coucou RN". Où ce changement sera-t-il visible, et où ne le sera-t-il PAS encore ?

3. Sans lancer la commande : que ferait npx expo run:android sur votre machine actuelle, et pourquoi échouerait-il probablement aujourd’hui ?

🧠 Quiz

1. Que contient le template par défaut de create-expo-app en SDK 57 ?

2. Quelle est la différence de rôle entre package.json et app.json ?

3. npx expo start compile-t-il du code natif ?

4. Quel est le premier réflexe face à un comportement inexplicable en dev ?

5. Pourquoi le projet généré n’a-t-il pas de dossier android/ ?

👉 Chapitre suivant : 2.2 — Ton téléphone = machine de dev — on scanne ce QR code.