Packages et dépendances
Vocabulaire npm et rangement dependencies/devDependencies.
Objectifs
À la fin de cette leçon, vous saurez :
- définir bibliothèque, framework, package et dépendance ;
- distinguer dépendances et devDependencies ;
- comprendre le rôle du registre npm.
🔗 Pour vous rafraîchir la mémoire : dépôts distants (clone, push, pull) · codes de retour ($?, &&, ||) · redirections et pipes
Le vocabulaire démêlé
| Terme | Définition |
|---|---|
| bibliothèque | du code réutilisable QUE VOUS appelez (pg, lodash) |
| framework | une structure qui VOUS appelle selon ses règles (NestJS, Angular) |
| package | l'unité de distribution npm : code + manifeste + version |
| dépendance | un package dont votre projet a besoin pour tourner |
| devDependency | un package utile seulement en développement (tests, linters) |
La distinction bibliothèque/framework est la phrase célèbre : « une bibliothèque, c'est vous qui appelez ; un framework, c'est lui qui vous appelle » (inversion of control). Vous l'avez déjà vécue : votre routeur maison vous laisse tout contrôler (bibliothèque) ; NestJS imposera sa structure (framework).
Le registre : la grande bibliothèque
npmjs.com héberge des millions de packages. npm install pg télécharge depuis ce registre, dans node_modules/, et note la dépendance dans package.json :
{
"dependencies": {
"pg": "^8.11.0"
},
"devDependencies": {
"jest": "^29.0.0"
}
}
Règle de rangement :
nécessaire EN PRODUCTION → dependencies
uniquement pour développer/tester → devDependencies
Exemples concrets : pg en dependencies ; jest, eslint, typescript en devDependencies — l'application déployée n'exécute jamais les tests.
Ce que chaque fichier apporte
package.json VOS dépendances directes + scripts
package-lock.json versions EXACTES de tout l'arbre (directes + transitives)
node_modules/ les fichiers réels installés (ne se versionne JAMAIS)
Le lockfile rend les installations reproductibles : sur votre machine comme sur le serveur de déploiement, exactement les mêmes versions. C'est pourquoi il se versionne dans Git, contrairement à node_modules.
Réinstaller proprement
git clone <votre-projet> # node_modules absent !
cd votre-projet && npm install # lit package-lock.json et reconstruit tout
Exercice
- Dans votre projet todo, classez : pg, jest, eslint, express — dependencies ou devDependencies ?
- Supprimez node_modules puis lancez
npm install: vérifiez que tout revient. - Que se passerait-il si deux développeurs installaient sans lockfile ?
Résumé
- Bibliothèque vs framework = sens de l'appel.
- dependencies vs devDependencies = prod vs développement.
- package.json décide, lockfile verrouille, node_modules contient.
Correction disponibleCherchez d’abord par vous-même.Voir la correction
Correction
Réponses détaillées
Question 1. pg → dependencies. express → dependencies. jest, eslint → devDependencies.
Question 3. Chacun obtiendrait potentiellement des versions différentes (npm résout alors les plages ^~ à la dernière version compatible) : bugs « chez moi ça marche » garantis. Le lockfile élimine cette classe entière de problèmes.