Construire et mettre en ligne
Passer du serveur de développement à des fichiers prêts à être hébergés, sans y laisser de secret.
Objectifs de la séance
- comprendre ce que produit
npm run buildet ce que contientdist/; - tester la version de production avec
npm run preview; - utiliser les variables d'environnement de Vite (
VITE_...) ; - comprendre pourquoi aucun secret n'a sa place dans une application Web ;
- anticiper les deux pièges de l'hébergement : le sous-dossier et les adresses internes ;
- créer une commande de vérification avant la mise en ligne.
Petite vérification
Avant de commencer, vérifiez si vous savez...
- lancer
npm testet lire les deux lignes de bilan (fichiers de test et tests) - dire pourquoi un test ne doit jamais appeler le vrai réseau
- dire à quoi sert la fonction
cleanupdanssrc/setupTests.ts
📌 Réponse attendue
Notions théoriques
Développement et production : deux modes
Développement (npm run dev) | Production (npm run build) | |
|---|---|---|
| Fichiers servis | modules séparés, à la demande | quelques fichiers regroupés et minifiés |
| Rechargement | automatique à chaque sauvegarde | aucun |
| StrictMode | effets exécutés deux fois | effets exécutés une fois |
| Vérification des types | non bloquante | bloquante (tsc -b avant vite build) |
| Usage | écrire le code | publier |
Construire l'application
npm run build
La commande vérifie les types, puis fabrique le dossier dist/ :
dist/
├── index.html ← la page, qui charge les fichiers ci-dessous
├── favicon.svg ← copié depuis public/
├── questions.json ← copié depuis public/
└── assets/
├── index-CuOtdXiT.css
└── index-DtAsiMrN.js ← tout votre code React, regroupé et minifié
Les noms des fichiers de assets/ contiennent une empreinte (DtAsiMrN) qui change dès que le contenu change : le navigateur ne risque pas d'utiliser une ancienne version en cache.
Le dossier dist/ est généré : on ne le modifie jamais à la main et on ne l'envoie pas sur Git (il est dans le .gitignore).
Tester la version de production
npm run preview
Cette commande sert le contenu de dist/ sur http://localhost:4173. C'est la vraie version qui sera publiée : testez-y un parcours complet, comme le ferait un utilisateur.
Les variables d'environnement
Certains réglages changent selon l'endroit où l'application est installée (le nom affiché, l'adresse d'une API). Vite les lit dans un fichier .env à la racine du projet. Seules les variables dont le nom commence par VITE_ sont rendues accessibles au code.
VITE_NOM_APPLICATION=Quiz Cyber BTS SIO
SECRET_SERVEUR=ne-doit-jamais-apparaitre
const nomApplication = import.meta.env.VITE_NOM_APPLICATION ?? "Quiz Cyber";
Notez le ?? : une variable peut être absente, on prévoit une valeur par défaut.
Pour que TypeScript connaisse la variable, on la déclare dans src/vite-env.d.ts :
/// <reference types="vite/client" />
interface ImportMetaEnv {
readonly VITE_NOM_APPLICATION?: string;
}
interface ImportMeta {
readonly env: ImportMetaEnv;
}
Deux règles :
- la valeur est copiée dans le code au moment du build : modifier
.envdemande de relancernpm run build; .envest un fichier de réglages publics. Un fichier.env.local(ignoré par Git grâce à la ligne*.localdu.gitignore) sert aux réglages personnels.
Tout ce qui est dans dist/ est téléchargé par le navigateur de chaque visiteur, et lisible par n'importe qui avec les outils de développement. Une variable VITE_... finit en clair dans le fichier JavaScript. Ne mettez donc jamais dedans un mot de passe, une clé d'API privée ou un jeton d'administration. Un secret reste sur un serveur, que l'application interroge.
Vérifiez-le : cherchez le texte ne-doit-jamais-apparaitre dans les fichiers de dist/assets/. Il n'y est pas, car la variable SECRET_SERVEUR ne commence pas par VITE_. En revanche Quiz Cyber BTS SIO y apparaît bien.
Deux pièges d'hébergement
1) Le sous-dossier. Si l'application est publiée dans https://exemple.fr/quiz/ et non à la racine du site, les fichiers sont cherchés au mauvais endroit. On l'indique dans vite.config.ts avec l'option base: "/quiz/". Bonne nouvelle : le code utilise déjà import.meta.env.BASE_URL pour charger questions.json.
2) Les adresses internes. Avec BrowserRouter, l'adresse /partie/2 n'existe que dans JavaScript. Si l'utilisateur recharge la page ou ouvre ce lien directement, le serveur cherche un fichier /partie/2 et répond 404. L'hébergeur doit donc être configuré pour répondre index.html à toute adresse inconnue (on parle de règle de réécriture ou de fallback SPA). Selon l'hébergeur, c'est un réglage à cocher ou un petit fichier de configuration.
Un dossier dist/ est un simple ensemble de fichiers statiques : n'importe quel hébergeur de sites statiques convient (le serveur Web du lycée, un hébergeur gratuit de sites statiques...). La seule exigence est la règle de réécriture vers index.html évoquée ci-dessus.
Une commande de vérification avant publication
Avant de publier, on enchaîne toutes les vérifications dans l'ordre : analyse du code, tests, build. Une seule commande évite d'en oublier une.
{
"scripts": {
"verifier": "npm run lint && npm test && npm run build"
}
}
Le symbole && signifie : « exécute la suivante seulement si la précédente a réussi ». Au premier échec, tout s'arrête.
Test de mémorisation/compréhension
TP pour réfléchir et résoudre des problèmes
Votre mission : construire l'application, la tester en mode production, ajouter un réglage d'environnement et une commande de vérification.
Étape 1 — Construire
Lancez la construction et repérez le dossier dist/.
Un fichier JavaScript de quelques centaines de ko est normal pour une application React. S'il grossit brutalement après l'ajout d'une bibliothèque, c'est un signal à examiner.
Étape 2 — Tester la version de production
Servez dist/ et jouez une partie complète.
Le mode développement et le mode production peuvent se comporter différemment (StrictMode, chemins des fichiers). Testez toujours la version construite avant de publier.
Étape 3 — Déclarer une variable d'environnement
Créez le fichier .env à la racine du projet, puis déclarez la variable pour TypeScript.
Le ? après le nom indique que la variable peut manquer (fichier .env absent, autre environnement). Le code prévoit toujours une valeur par défaut.
Étape 4 — Utiliser la variable dans l'en-tête
Affichez le nom de l'application dans EnTete, avec une valeur par défaut.
La constante est lue au chargement du fichier, hors du composant : inutile de la relire à chaque affichage.
Étape 5 — La commande de vérification
Ajoutez le script verifier dans package.json.
Avant chaque mise en ligne : npm run verifier passe, aucun console.log de débogage ne traîne, la page /nimporte/quoi affiche la page 404, aucun secret n'est présent dans dist/, et un parcours complet a été joué avec npm run preview.
📌 Une solution
Ce qu'il faut retenir
| Notion | Résumé |
|---|---|
npm run build | Vérifie les types puis fabrique dist/ (fichiers regroupés, minifiés, avec empreinte). |
npm run preview | Sert dist/ en local pour tester la vraie version. |
Variables VITE_ | Réglages publics copiés dans le code au build ; valeur par défaut avec ??. |
| Secrets | Jamais dans une application Web : tout dist/ est lisible par les visiteurs. |
| Hébergement | Option base pour un sous-dossier ; réécriture vers index.html pour les adresses internes. |
npm run verifier | Enchaîne analyse, tests et build avant chaque publication. |
Aperçu de la prochaine séance
Votre application est testée et prête à être publiée, mais elle reste très sobre visuellement. Dans le dernier tutoriel, vous allez l'habiller avec Tailwind CSS et shadcn/ui : des boutons, des cartes et une fenêtre modale de qualité professionnelle, dont vous contrôlez entièrement le code.