1.4npm : package.json, dépendances, scripts, versions
L'essentiel en 30 secondes
- package.json = le manifeste : nom, version, dépendances, scripts — créé avec npm init, point de référence de tout projet.
- La recette, pas le résultat : on versionne package.json + package-lock.json (versions exactes), jamais node_modules (régénérable via npm install).
- Semver + scripts + audit : MAJEUR.MINEUR.CORRECTIF (^ et ~), commandes standard via npm run, vulnérabilités via npm audit.
Mini-cas filé — Salim initialise son projet à Alger
Salim récupère le projet de la startup : un dossier avec du code mais aucun package.json, et un collègue lui envoie node_modules en pièce jointe. Il repart proprement : npm init pour créer le manifeste, installation des paquets (dépendances vs devDependencies), scripts start/dev/test, .gitignore qui exclut node_modules, et un premier npm audit qui révèle une dépendance vulnérable à mettre à jour. Le projet devient installable en une commande : npm install.
Dernier épisode du cas 1.1-1.3 — Salim outille son projet après le langage, l'asynchrone et les modules.
1. package.json & dépendances : le manifeste
npm donne accès au plus grand registre open source au monde : on installe des paquets au lieu de tout coder. Le cœur du projet est package.json (nom, version, dépendances, scripts), créé avec npm init. npm install express télécharge dans node_modules et ajoute aux dépendances. On distingue dependencies (production) et devDependencies (dev seulement, -D). Le package-lock.json verrouille les versions exactes (reproductibilité) ; node_modules n'est pas versionné (régénérable).
Salim lance npm init -y, installe le framework en dépendance et l'outil de redémarrage en devDependency : le projet s'installe désormais d'un npm install sur n'importe quel poste.
2. Semver, scripts & sécurité
Le versionnage sémantique (semver) suit MAJEUR.MINEUR.CORRECTIF : majeur = changements cassants, mineur = nouveautés compatibles, correctif = bugs. ^4.18.2 autorise les mises à jour mineures/correctives, ~4.18.2 les correctives seulement. Les scripts (start, dev, test) se lancent avec npm run <nom> et standardisent les commandes. Et npm audit signale les vulnérabilités des dépendances — à surveiller, car les failles de dépendances sont un vrai risque.
Salim définit start, dev et test dans ses scripts et fait de npm audit son réflexe avant chaque mise en production.
3. Choisir ses paquets sans s'exposer
L'écosystème immense est une force (ne pas réinventer la roue) et un risque (failles, qualité variable, paquets abandonnés). Pour choisir : popularité (téléchargements, adoption), maintenance active (mises à jour récentes, issues traitées), documentation sérieuse, périmètre minimal (pas de gros paquet pour une fonction triviale). Et côté Git : on versionne package.json + lock, jamais node_modules ni les secrets (.env).
Salim vérifie les téléchargements et la dernière mise à jour avant d'installer, et ajoute node_modules/ et .env au .gitignore dès le premier commit.
🔎 Exemple concret — 🔎 Exemple concret — Initialiser et installer
Les commandes de base, dans l'ordre.
npm init -y # cree package.json
npm install express # dependance (production)
npm install -D nodemon # devDependency (dev)
npm run dev # lance le script "dev"
npm audit # vulnerabilites connuesLecture : -D marque les outils de dev ; npm run lance les scripts du manifeste.
Leçon : ignorer node_modules et .env dans .gitignore — réflexe dès le premier commit.
Vocabulaire de la section
- npm & le registre
- Gestionnaire de paquets de Node, donnant accès au plus grand registre open source au monde (des centaines de milliers de bibliothèques réutilisables).
Exemple simple : Le framework web installé par Salim au lieu d'être recodé.
Ce que ce n'est pas : recoder soi-même un routeur HTTP ou un client de base.
Réflexe : chercher le paquet éprouvé avant de recoder.
- package.json
- Manifeste du projet : nom, version, dépendances, scripts, métadonnées. Créé avec npm init ; point de référence de tout projet Node.
Exemple simple : Le package.json de Salim avec start, dev et test.
Ce que ce n'est pas : un dossier de code sans manifeste, ininstallable proprement.
Réflexe : npm init dès le premier jour du projet.
- dependencies vs devDependencies
- dependencies : nécessaires en production. devDependencies : utiles en dev seulement (installées avec -D). node_modules : dossier des paquets installés, non versionné, régénérable.
Exemple simple : Le framework en dependencies, l'outil de redémarrage en devDependencies chez Salim.
Ce que ce n'est pas : envoyer node_modules en pièce jointe au collègue.
Réflexe : -D pour les outils, Git ignore node_modules.
- package-lock.json
- Fichier verrouillant les versions EXACTES installées ; garantit que tout le monde installe rigoureusement les mêmes versions (reproductibilité).
Exemple simple : Le lock qui fait que le poste de Salim et la production installent la même chose.
Ce que ce n'est pas : « ça marche chez moi » avec des versions différentes partout.
Réflexe : versionner le lock, ne jamais l'éditer à la main.
- semver & scripts npm
- Versionnage MAJEUR.MINEUR.CORRECTIF (^ autorise mineures/correctives, ~ correctives seulement). Les scripts définissent des commandes réutilisables (npm run
). Exemple simple : Le ^ qui laisse passer les correctifs de sécurité chez Salim, et son npm run dev.
Ce que ce n'est pas : des versions figées à jamais ou des commandes différentes par développeur.
Réflexe : comprendre ^ / ~, standardiser via les scripts.
En pratique — En pratique — Gérer un projet avec npm
- Initialisez un projet avec npm init -y et examinez le package.json généré (nom, version, scripts).
- Installez un paquet (npm install express) et une devDependency (npm install -D nodemon) ; observez node_modules, package.json et package-lock.json.
- Ajoutez des scripts au package.json ("start", "dev") et lancez-les avec npm start / npm run dev.
- Comprenez le semver (^ vs ~), ignorez node_modules (.gitignore), et lancez npm audit pour repérer les vulnérabilités.
Script prêt à dire — cadrer l'hygiène npm en équipe (30 s)
« On versionne package.json et le lock, jamais node_modules — chacun régénère avec npm install. Les outils de dev passent en -D, les commandes en scripts, et on fait un npm audit avant chaque livraison. »
À dire au démarrage du projet ; vérifier le .gitignore au premier commit.
Modèle copier-coller — package.json minimal + .gitignore
{
"name": "projet-salim",
"version": "1.0.0",
"scripts": {
"start": "node app.js",
"dev": "nodemon app.js",
"test": "jest"
},
"dependencies": {},
"devDependencies": {}
}
// .gitignore :
// node_modules/
// .envProjet sans manifeste
Comme Salim : npm init -y, réinstaller les paquets un par un en distinguant prod et -D, recréer les scripts — ne jamais récupérer un node_modules d'autrui.
Équipe à Alger
Scripts start/dev/test identiques pour tous : chaque développeur lance les mêmes commandes, fini le « moi je faisais autrement ».
Montée de version prudente
Lire ce que ^ et ~ autorisent avant de mettre à jour ; tester après chaque montée mineure, verrouiller via le lock.
Livraison imminente
npm audit avant de livrer : corriger les vulnérabilités signalées, vérifier que .env et node_modules sont bien hors Git.
✓ Bonnes pratiques
- Versionner json + lock, jamais node_modules.
- Outils de dev en -D, commandes en scripts.
- npm audit avant chaque livraison.
✗ Pièges fréquents
- Versionner node_modules.
- Oublier .env dans .gitignore.
- Ignorer les alertes npm audit.
Points clés à retenir
- npm donne accès au plus grand registre open source au monde : installer des paquets au lieu de tout coder — accélérateur majeur.
- package.json = manifeste (dépendances, scripts) ; package-lock.json verrouille les versions EXACTES. node_modules NON versionné (régénérable).
- dependencies (production) vs devDependencies (dev, -D) ; SEMVER MAJEUR.MINEUR.CORRECTIF (^ mineures/correctives, ~ correctives).
- SCRIPTS npm standardisent les commandes ; npm audit signale les vulnérabilités (à surveiller).
Défi 48h — appliquez demain
Initialisez un vrai projet (modèle ci-dessus) : npm init -y, 1 paquet + 1 devDependency (-D), 2 scripts, .gitignore (node_modules, .env), puis npm audit. 25 minutes suffisent.
- Je peux expliquer package.json, lock et node_modules.
- Je sais distinguer dependencies, devDependencies et semver ^ / ~.
- J'ai un projet installable via npm install + audité.
Questions fréquentes
Que faut-il versionner (Git) dans un projet Node, et pourquoi pas node_modules ?
Versionnez votre code, package.json (la « recette » : dépendances, scripts) et package-lock.json (les versions exactes, y compris sous-dépendances) — plus le .gitignore, le README et les configs. Ne versionnez jamais node_modules : c'est énorme (milliers de fichiers), régénérable par npm install à partir des deux manifestes, et parfois spécifique à la plateforme. Comme Salim : on partage la recette (json + lock), chacun régénère le résultat. Excluez aussi les secrets (.env), logs et temporaires.
L'écosystème npm est immense : comment choisir de bons paquets ?
Ne pas réinventer la roue est un atout majeur — mais les dépendances sont aussi un risque (failles, qualité variable, abandon). Pour choisir : popularité (téléchargements, étoiles — un bon signal), maintenance active (mises à jour récentes, issues traitées), documentation sérieuse, périmètre minimal (pas de gros paquet pour une broutille). Puis gérez : tenez les dépendances à jour (semver compris), surveillez npm audit, et préférez peu de dépendances éprouvées à une myriade d'inconnues.
Que faut-il versionner dans Git pour un projet Node ?