Qualité et mise en ligne

Ce que tu vas apprendre

• Détecter les erreurs et uniformiser le style automatiquement avec ESLint et Prettier.
• Écrire un premier test et faire relire ton code par une pull request.
• Préparer une mise en ligne : build, variables d'environnement de production et vérifications.

Laisser les outils vérifier à ta place

Relire chaque ligne à la main est long et fatigant. Des outils le font en quelques secondes. Ils attrapent les fautes de frappe, les variables inutilisées et les différences de style avant qu'un humain n'ait à s'en occuper.

ESLint : repérer les problèmes

ESLint analyse ton code JavaScript sans l'exécuter et signale les erreurs probables : variable jamais utilisée, nom inexistant, mauvaise habitude. Pour l'installer dans un projet, la documentation propose :

npm init @eslint/config@latest

Un assistant pose quelques questions et crée le fichier de configuration eslint.config.js. Ensuite, lance l'analyse :

npx eslint .
npx eslint . --fix

La seconde commande corrige automatiquement ce qui peut l'être. Le reste est à corriger à la main, en lisant le message : chaque règle a un nom, et la documentation l'explique.

Prettier : un style unique

Prettier réécrit ton code avec une mise en forme cohérente : indentation, guillemets, retours à la ligne. Plus de débats sur le style dans une équipe.

npm install --save-dev --save-exact prettier
npx prettier . --write
npx prettier . --check

--write modifie les fichiers. --check vérifie sans rien changer, ce qui sert dans une vérification automatique. Un fichier .prettierrc à la racine peut contenir des options, ou simplement {} pour garder les valeurs par défaut.

Un premier test

Un test est du code qui vérifie qu'un autre code fait ce qu'il doit. Il te protège quand tu modifies quelque chose : si un test casse, tu le sais tout de suite.

Node.js inclut un lanceur de tests. Voici un test pour la fonction calculerDuree du site de recettes :

import { test } from 'node:test'
import assert from 'node:assert'
import { calculerDuree } from './duree.js'

test('additionne préparation et cuisson', () => {
  assert.strictEqual(calculerDuree({ preparation: 15, cuisson: 30 }), 45)
})

Lance-le avec :

node --test

Si tu préfères un outil plus complet, Vitest s'installe avec npm install -D vitest et se lance avec npx vitest.

La revue de code et les pull requests

Une pull request (« requête de tirage » dans la documentation GitHub) propose de fusionner une branche dans une autre. Avant la fusion, d'autres personnes relisent les changements, commentent et demandent des modifications.

Les bonnes pratiques :

1. Garde la pull request petite : un sujet à la fois.
2. Décris ce qui change, pourquoi, et comment le tester.
3. Relie l'issue avec Closes #12.
4. Relis ton propre diff avant de demander une relecture.
5. Reçois les remarques comme une aide pour le code, pas comme une critique de toi.

GitHub permet d'ajouter un modèle de pull request pour que chaque proposition suive la même trame. Même seul, ouvrir une pull request pour tes propres changements te force à relire avant de fusionner.

Préparer la mise en ligne

Mettre en ligne, c'est transformer ton projet de développement en version optimisée pour le public. Avec Nuxt, la commande est :

npm run build

Elle produit le dossier .output. Le résultat est ce que ton hébergeur exécute, pas ton code source.

Les variables d'environnement en production

Le fichier .env est lu par Nuxt en développement et au moment du build, mais pas par le serveur compilé en production. Tu dois définir les variables dans l'interface de ton hébergeur, avec les mêmes noms.

Dans Nuxt, la configuration d'exécution se déclare dans nuxt.config.ts :

export default defineNuxtConfig({
  runtimeConfig: {
    apiSecret: '',
    public: { apiBase: '' }
  }
})

Les variables NUXT_API_SECRET et NUXT_PUBLIC_API_BASE remplacent ces valeurs au démarrage. Tout ce qui est sous public est visible par les visiteurs : n'y mets jamais de secret. Lis les valeurs avec useRuntimeConfig().

Vérifier avant de déployer

Une liste de contrôle à parcourir à chaque mise en ligne :

Après le déploiement, ouvre le site, vérifie la console du navigateur et teste le parcours principal. Garde sous la main le moyen de revenir à la version précédente.

À retenir

• ESLint repère les erreurs probables, npx eslint . --fix corrige ce qui est automatique.
• Prettier uniformise le style, --check vérifie et --write réécrit.
• Un test vérifie une fonction et se lance avec node --test ou Vitest.
• Une pull request petite, décrite et relue vaut mieux qu'un gros envoi sans explication.
• npm run build prépare le site, mais le .env n'est pas lu par le serveur en production.
• Passe une liste de vérifications avant chaque déploiement, puis teste le site en ligne.