Le .zip d'un projet React Native

En résumé : zippez votre dossier de projet avec vos dossiers natifs ios/ et android/, votre package.json et votre lockfile, et vos éventuelles dépendances privées — mais sans node_modules/, sans les caches natifs, ni les dossiers de build.

Ce que l'archive doit contenir

• package.json — la carte d'identité du projet, à la racine de l'archive.
• Votre lockfile — package-lock.json, yarn.lock, pnpm-lock.yaml ou bun.lockb : il fige les versions exactes de vos dépendances, pour un build identique à celui que vous testez en local.
• ios/ et android/ — les dossiers plateforme (Podfile, projet Xcode, build.gradle, permissions…). Le build en a besoin, même si vous n'y avez jamais touché.
• Votre code — App.tsx, src/, index.js, etc.
• Vos assets — images, polices et autres fichiers référencés par l'app.
• Les fichiers de configuration utilisés par l'app, s'ils existent : google-services.json (Firebase Android), GoogleService-Info.plist (Firebase iOS), fichiers .env lus au moment du build, etc.

Une archive bien formée ressemble à ceci :

mon-app.zip
├── package.json
├── yarn.lock            ← ou package-lock.json / pnpm-lock.yaml
├── .nvmrc              ← recommandé : la version de Node
├── App.tsx
├── src/
├── ios/
├── android/
└── assets/

Dépendances locales et privées : à inclure

Nous compilons uniquement ce qui est dans l'archive. La machine de build n'a accès ni à votre ordinateur, ni à vos dépôts git privés, ni à vos registres npm privés. Donc :

• Les dépendances locales (file:../mon-package) doivent être incluses dans le .zip, avec des chemins relatifs qui restent valables à l'intérieur de l'archive. Si un chemin pointe hors de l'archive (../mon-package), déplacez le package dans le projet et mettez le chemin à jour.
• Les dépendances venant d'un git privé ou d'un registre npm privé doivent être copiées dans le projet (ou vendorisées), car le build ne peut pas s'y connecter.

Ce que Releasely télécharge pour vous

Inutile de les mettre dans l'archive — elles sont récupérées automatiquement pendant le build :

• les packages npm (npm ci / yarn install / pnpm install est exécuté pour vous, selon votre lockfile) ;
• les CocoaPods iOS (pod install tourne sur le Mac de build) ;
• la version de Node que vous avez épinglée (installée à la demande, jamais figée côté serveur).

Ce que vous pouvez exclure

Ces dossiers sont régénérés au build — les inclure ne fait qu'alourdir l'envoi :

• node_modules/ — réinstallé depuis votre lockfile (souvent le plus gros dossier : à exclure en priorité) ;
• ios/Pods/ et android/.gradle/ — les caches des dépendances natives ;
• ios/build/, android/app/build/ — les artefacts de compilation ;
• .git/ — l'historique de votre dépôt ;
• .idea/, *.iml, .vscode/ — la configuration de votre éditeur.

Sur macOS ou Linux, cette commande crée une archive propre depuis la racine du projet :

zip -r mon-app.zip . -x "node_modules/*" "ios/Pods/*" "ios/build/*" "android/.gradle/*" "android/app/build/*" ".git/*" ".idea/*" ".vscode/*"

Signature : jamais dans le .zip

Taille et numéro de build

• 2 Go maximum par archive — largement suffisant pour un projet sans node_modules ni dossiers de build.
• Le numéro de build est incrémenté automatiquement à partir du dernier build connu ; un champ sur l'écran Upload permet de le forcer si vous devez rattraper un numéro déjà utilisé sur les stores. Il est imposé au build sans modifier votre build.gradle ni votre projet Xcode.

Et ensuite ?

Une fois l'archive envoyée, Releasely lance le build cloud (iOS et/ou Android selon votre projet) et le binaire produit rejoint automatiquement votre prochaine version.