La gestion des dépendances est le talon d'Achille de nombreux déploiements. Une mise à jour imprévue d'un sous-paquet transitif peut faire planter votre serveur de production alors que tout fonctionnait hier. Découvrez les règles impératives de reproductibilité avec npm ci, le verrouillage de version et l'isolation des dépendances de build.
Ne lancez jamaisnpm install sur un serveur de production ou en CI/CD : utilisez exclusivement npm ci.
Le fichier de verrouillage contenant l'arbre exact, les sommes de contrôle SHA-512 et les versions figées de chaque sous-module.
Pour une API en production, purgez les outils de développement (Jest, ESLint, TypeScript) via --omit=dev.
Anticipez les alertes de sécurité dans la chaîne d'approvisionnement (Supply Chain Attacks) avec npm audit.
Cliquez sur chaque commande pour simuler son comportement sur un serveur de déploiement :
node_modules/ existant et reconstruit l'arborescence exacte dictée par le lockfile.package-lock.json. Si le lockfile et le package.json sont désynchronisés, il plante immédiatement (Fail-Fast). Dans une application backend déployée avec Docker, inclure les devDependencies (comme TypeScript et Jest) fait exploser l'image Docker de 150 Mo à plus de 1 Go. Voici le pattern moderne du Multi-stage Build :
# Étape 1 : Construction et compilation (Builder)
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
# Installation de TOUTES les dépendances (y compris devDependencies pour compiler le TypeScript)
RUN npm ci
COPY . .
RUN npm run build
# Étape 2 : Image finale de production ultra-légère (Runtime)
FROM node:20-alpine AS runner
WORKDIR /app
ENV NODE_ENV=production
COPY package*.json ./
# Installation STRICTEMENT des dépendances de production
RUN npm ci --omit=dev
# Copie uniquement des fichiers compilés du stage précédent
COPY --from=builder /app/dist ./dist
USER node
EXPOSE 3000
CMD ["node", "dist/main.js"] Quand npm affiche des vulnérabilités, beaucoup de développeurs exécutent aveuglément npm audit fix --force.
--force installe des versions majeures (Breaking Changes) de vos bibliothèques. Cela brise fréquemment des fonctionnalités entières en production sans que vous ne vous en rendiez compte ! Comment traiter les alertes de sécurité en production :
npm audit seul pour identifier les paquets affectés.npm audit fix (sans --force) pour les patchs non destructifs.devDependency, l'impact en production est généralement nul car ces paquets ne tournent pas sur le serveur.