La règle d'or des équipes d'ingénierie de haut niveau est la tolérance zéro pour les avertissements. Un avertissement ignoré en développement devient systématiquement une panne silencieuse, une fuite de mémoire ou un crash complet une fois soumis à la charge réelle des utilisateurs en production.
Interdire tout déploiement dès qu'un seul warning subsiste dans le rapport de linting.
Vérification stricte de tous les types TypeScript en mémoire sans écrire un seul fichier sur le disque.
Bloquer le commit local dès qu'un fichier non conforme tente d'entrer dans l'historique Git.
Intercepter les promesses asynchrones sans .catch() qui font crasher Node.js.
Sélectionnez une anomalie fréquente pour comprendre son impact en production et sa correction immédiate :
Un appel asynchrone (ex: sauvegarde en base ou envoi d'email) est exécuté sans await ni .catch().
// ❌ Dangereux en production :
userService.sendWelcomeEmail(user.id);
// ✅ Sécurisé avec gestion d'erreur dédiée :
try {
await userService.sendWelcomeEmail(user.id);
} catch (error) {
logger.error('Échec envoi email bienvenu', { userId: user.id, error });
} Ne comptez pas sur la mémoire humaine. En configurant Husky, chaque développeur de l'équipe voit son git commit intercepté pour valider le typage et le linting uniquement sur les fichiers modifiés :
# 1. Installer Husky et lint-staged
npm install --save-dev husky lint-staged
# 2. Initialiser Husky
npx husky init
# 3. Dans .husky/pre-commit :
npx lint-staged
# 4. Dans package.json :
{
"lint-staged": {
"*.{ts,tsx}": [
"eslint --max-warnings=0",
"bash -c 'tsc --noEmit'"
]
}
} Vous maîtrisez à présent l'audit local, l'étanchéité des variables d'environnement (.env), l'immutabilité des dépendances (npm ci), les scripts universels (build / start), l'optimisation de bundle et la tolérance zéro aux erreurs. Vous êtes prêt à aborder le Chapitre 3 : Déploiement d'un site web statique.