Web frontend · L2 · Section 5/6
Outils et workflow
Progression
#Outils et workflow
Un bon workflow remplace la mémoire et la bonne volonté par des mécanismes : le formatage standardise, le lint refuse les erreurs connues, les tests verrouillent les comportements, la CI rejoue tout sur une machine propre. La simplicité compte plus que l'exhaustivité : trois scripts bien nommés valent mieux qu'un outillage opaque que personne n'ose toucher.
#De l'IDE à la prod : vision d'ensemble
Les incidents viennent presque toujours des « trous » entre ces étapes : un linter configuré différemment en local et en CI, des tests qui passent chez vous mais pas ailleurs faute de variable d'environnement, un build non déterministe qui produit un artefact différent du même commit. Le remède est unique : la même commande, le même environnement, du commit à la prod.
#Garde-fous continus, étape par étape
Le formatage (Prettier) et le lint (ESLint) tournent dans l'éditeur, à la sauvegarde. Les écarts de style disparaissent avant même d'exister dans un commit ; les erreurs triviales (variable non utilisée, == accidentel) se soulignent.
#Script unique, reproductible
Centralisez la vérification dans une commande check qui enchaîne type-check, lint et tests. La même commande tourne en local avant de pousser et en CI sur la PR : c'est la garantie anti-dérive.
1{2 "scripts": {3 "format": "prettier --write .",4 "lint": "eslint .",5 "typecheck": "tsc -p tsconfig.json --noEmit",6 "test": "vitest run",7 "check": "npm run typecheck && npm run lint && npm run test"8 }9}Deux règles d'hygiène qui évitent les faux positifs de CI : commitez le lockfile (l'installation est alors déterministe), et épinglez les versions d'outils (Node via .nvmrc ou engines, actions GitHub sur des tags précis). Un build qui change selon la machine qui l'exécute n'est pas un build, c'est une loterie.
#Exercice
Ajoutez un hook de pré-commit qui lance formatage, lint et tests ciblés sur les fichiers modifiés (par exemple via husky + lint-staged). Puis vérifiez le mécanisme :
- Introduisez volontairement une erreur de lint dans un fichier et tentez de commiter : le commit doit être refusé localement.
- Forcez le commit (
--no-verify) et poussez une PR : la CI doit échouer sur la même règle, avec le même message.
La deuxième étape est la vraie preuve : le hook local est une commodité, la CI est le contrat.
Correction guidée
- Installez les outils :
npm i -D husky lint-stagedpuisnpx husky init. - Dans
.husky/pre-commit:npx lint-staged. - Dans
package.json:"lint-staged": { "*.{js,ts,tsx}": ["eslint --fix", "prettier --write"] }. - Test 1 : une variable inutilisée fait échouer ESLint, le commit est bloqué.
- Test 2 :
git commit --no-verifypasse le hook, mais la CI rejouenpm run checket échoue. Conclusion : jamais une règle ne vit uniquement en local.