:::: MENU ::::

Comprendre et maîtriser npm – Introduction

Npm est désormais incontournable pour les développeurs javascript . Apparu avec node.js en 2009 son usage dépasse aujourd’hui l’environnement serveur. Il est de plus en plus utilisé pour des applications front et son usage comme outil de développement devient quasi systématique. De plus il reste simple et permet d’accéder au plus gros dépôt de paquets tout langages confondus.

Simple mais extrêmement puissant ! Dans cette série d’articles nous verrons dans un premier temps comment prendre en main npm puis après quelques astuces utiles aux débutants et confirmés nous irons un peu plus loin en l’utilisant comme système de build à part entière et en créant nos propres paquets pour la plateforme .

Installation

Pas besoin ici de grandes explications, npm est fourni lors de l’installation de nodejs . Vous pouvez aussi l’installer manuellement, dans ce cas il suffit de récupérer le dossier compressé depuis les sources et de placer les fichiers dans le dossier de node.js. Sous linux c’est encore plus simple car un script fait tout pour vous.

curl -L https://npmjs.com/install.sh | sh

Dès lors que vous avez configuré votre PATH correctement, c’est à dire pointant vers l’exécutable de npm qui se trouve en principe avec celui de node.js, vous pouvez suivre ce qui suit.

Commandes de base

Commencer un projet

npm init

Obligatoire Indispensable pour pouvoir utiliser npm avec votre projet . Cette commande va générer un fichier package.json qui décrit la configuration de votre projet. Chaque module de npm est configuré ainsi, ce qui fait que votre projet est par définition un paquet au même titre que les autres et donc potentiellement publiable sur npm .

Installer et désinstaller un paquet

Npm est un gestionnaire de paquet. L’usage le plus courant que l’on en fait est l’installation de dépendances depuis la plateforme npm .

npm install <nom_du_paquet>

Logique et simple, il en va de même pour la suppression :

npm uninstall <nom_du_paquet>

Il est intéressant de savoir que la commande d’installation ne se limite pas au téléchargement d’un paquet et de ses dépendances depuis la plateforme. Npm considère comme paquet valide :

  • Un dossier contenant un fichier package.json
  • Une archive gzip (contenant un dossier et le package.json associé )
  • Une url vers une archive gzip
  • Un paquet publié sur npm ( <nom_du_paquet>@<version> ou <nom_du_paquet>@<tag> ou <nom_du_paquet> )
  • Une adresse git qui fournit une archive

Il est aussi possible de configurer npm pour qu’il utilise un dépôt privé, nous verrons cela dans la suite

stock-footage-stack-of-new-folded-paper-box

npm est le plus gros dépôt de paquet tout langages confondus

 

 

Un paquet peut être installé globalement avec  l’option -g ce qui permet une utilisation à travers la ligne de commande de n’importe où. C’est le cas des task-runners (grunt gulp …) par exemple ou bien des outils de tests (mocha, jasmine..). Attention à l’usage de l’installation globale ! Si il peut sembler pratique d’avoir accès à des paquets de n’importe où sur le système sans devoir les réinstaller, la portabilité de votre module/programme ne sera plus assurée. En effet lors du déploiement sur un autre système, les dépendances globales éventuelles ne seront peut être pas résolues. Il peut aussi y avoir un conflit de version entre votre projet et un module au niveau global.

Préférez des dépendances locales, identifiées dans le fichier package.json

Pour les outils type CLI installable avec npm, vous pouvez aussi les gérer dans le package.json de votre projet comme une dépendance de développement. Il est très simple de lancer des commandes avec npm sans avoir besoin de spécifier le chemin complet de l’exécutable ( ce que nous verrons dans l’article suivant ) .

 

Déclarer ses dépendances

Généralement lorsqu’on travail sur un projet, il arrive un moment ou il faut quitter l’environnement de dev et si on a des dépendances, il va falloir les faire suivre. Plutôt que de les copier à la main, ce qui en plus polluerait complètement un gestionnaire de source, on va utiliser la gestion des dépendances de npm. C’est exactement le même principe que pour les autres langages qui utilisent des gestionnaires de paquet.

Npm distingue principalement deux types de dépendances : production et développement. Ces dépendances sont renseignées sous forme d’objet dans le fichier package.json.

...

"dependencies": {

    "angular": "1.4.0-beta.5",
    "react": "0.13.0-rc1",
...
},

"devDependencies": {
    "babel": "^4.6.4",
    "body-parser": "^1.12.0",
    "webpack-dev-server": "^1.7.0"
...
},

Lorsque vous distribuerez votre programme, il vous suffira de fournir vos sources et le fichier package.json.

On l’a vu plus haut, la commande install accepte un dossier contenant un fichier package.json. Lorsque vous faites npm install à la racine de votre projet, c’est comme si vous faisiez un npm install ./ et toutes les dépendances nécessaires vont s’installer. Il y a aussi un autre avantage si vous utilisez dans votre workflow un outil de build tel que browserify ou webpack car ceux ci permettront d’utiliser ( avec require() ) les modules installés par npm automatiquement

Lors de l’installation d’un paquet à l’aide de la CLI, vous pouvez l’enregistrer automatiquement dans le fichier package.json à l’aide l’option –save ou –save-dev suivant le cas.

npm install gulp --save-dev

Ceci installera la dernière version de gulp ( tagguée comme latest sur le dépot central ) et ajoutera une entrée correspondante dans devDependencies du package.json

Mettre à jour des dépendances

npm update <nom_du_paquet>

La commande update va mettre à jour le paquet mentionné à sa dernière version disponible ou suivant la version indiquée dans package.json.

#proTip En rajoutant l’option –save ou –save-dev à update, vous mettez aussi à jour le fichier package.json avec la nouvelle version

#proTip un npm update sans nom de paquet mettra à jour l’ensemble des dépendances

#proTip depuis la version 2.6.1 vous pouvez aussi l’utiliser sereinement update les dépendances globales

Numérotation de version

L’écosystème nodejs utilise majoritairement la méthode SemVer pour numéroter les versions des paquets. Npm introduit un certain nombre de patterns permettant de gérer plus finement les versions qu’avec une numérotation exacte :

Opérateurs de comparaison

Les opérateurs <  <=  >  >=  =  peuvent être combinés avec || ou un espace pour former une expression définissant un ensemble de versions

ex :  1.2.7 || >=1.2.9 <2.0.0 correspond aux versions 1.2.7 , 1.2.9 et 1.4.6 mais pas 1.2.8 ni 2.0.0

Jockers ou wildcards

Les métacaractères * – ~ ^ sont raccourcis pour éviter des expressions complexes .

X Range

* ( ou X ou x ) prendra toujours la dernière version disponible. Il peut être utilisé sur la version complète ou de manière partielle.

ex :  * équivaut à >=0.0.0 c’est à dire la dernière version disponible.

1.* équivaut à la dernière version de la branche 1 soit >=1.0.0 <2.0.0

Des changements majeurs et cassants peuvent survenir lors d’un changement de branche. Ce joker est à éviter en production

Hyphen Ranges

– détermine un intervalle inclusif .

ex : 1.2.3 – 2.3.4 équivaut à >=1.2.3 <=2.3.4 .

1.2.3 – 2 équivaut à >=1.2.3 <3.0.0

Tilde et Caret Ranges

On arrive à la petite difficulté avec les deux derniers caractères ~ et ^. La base est la même, c’est un intervalle qui commence à la version supérieure ou égale à celle indiquée. Pour le tilde, il va inclure la version mineure la plus récente mais sans changer de branche alors que pour le caret il inclura la version majeure la plus récente.

ex : ~1.2.3 équivaut à >=1.2.3 <1.3.0

^1.2.3 équivaut à >=1.2.3 <2.0.0

~ permet de prévenir des changements brutaux alors que ^ est plus permissif

Il est possible d’aller encore plus loin avec la numérotation de version sur npm notamment avec les tags ou même des fonctions. Si vous souhaitez en savoir plus, comme d’habitude, voici la doc

Conclusion

Vous avez désormais les bases pour bien utiliser npm, mais sachez que cet outil possède encore de belles surprises et peut être totalement intégré au workflow de dev et de déploiement, dans le prochain article nous verrons quelques astuces souvent bien utiles et certaines subtilités de configuration

Notes:
1. D’autre types de dépendances existent mais sont moins utilisées : peer , bundled , optional
D’autre types de dépendances existent mais sont moins utilisées : peer , bundled , optional