:::: MENU ::::

Maitriser npm : au coeur du workflow

Si npm permet de gérer simplement les dépendances de son projet, il propose également des fonctionnalités qui le place au centre du workflow de développement javascript / web . C’est ce que nous allons voir dans cette dernière partie consacrée à npm, le gestionnaire de paquets pour nodejs

Comprendre et maîtriser npm  : Introduction

Comprendre npm : astuces et configuration

Maitriser npm : au coeur du workflow

Npm comme outil de build

S’il y a bien un écosystème technique qui bouge actuellement, c’est javascript. Plus que du mouvement, c’est un bouillonnement : librairies , framework, specs, devtools, task-runners.. Il est souvent dur de s’y retrouver. Pire, la question de la pérennité peut parfois se poser quand on voit à quelle vitesse les outils apparaissent / disparaissent .

Prenons ici le cas des outils de build, les plus connus sont grunt et gulp mais de nombreux autres existent tel que brunch , broccoli ou bien encore mimosa . Chacun venant ses plugins, ses conventions, ses avantages et ses inconvénients.

A mon sens le véritable soucis est la multiplicité des solutions car on se retrouve à devoir gérer voir maîtriser différents outils pour faire la même chose suivant les projets. Vu le nombre de compétences et d’informations qu’un développeur doit connaitre, mieux vaut éviter d’en rajouter .

Npm lui est présent à l’origine vu que c’est lui qui va être utilisé comme installeur de ces différents outils.

Le fait est que la plupart du temps, les outils de build utilisés comme task-runners sont inutiles !

Généralement lorsque l’on développe autre chose qu’un hello-world on va être amené à répéter des taches plus ou moins longues. Dans le cas d’un site internet cela sera par exemple de la concaténation et minification , pour une application , un lint et des tests..

C’est le cas pour à peu prêt tout les langages , et c’est ce genre de tache que va effectuer un task-runner.

Mais ces taches sont elles si complexes qu’il faut forcément un outil dédié pour les lancer ? . La réponse est non.

Lorsque l’on installe grunt, des plugins existent pour tout , quand on utilise gulp, on est heureux de pouvoir écrire du javascript et d’utiliser des paquets existants Dans 80% des cas, les plugins des différents task-runners ne sont qu’une enveloppe pour lancer un outil existant en ligne de commande avec quelques paramètres.

Npm comme task-runner avec les scripts

Npm permet de lancer des actions à la fois prédéfinies lors des différentes phases de vie du logiciel ou bien personnalisées.

Pour utiliser cette fonctionnalité, il suffit de renseigner la partie scripts du fichier package.json . 

 


 "scripts": {
   "lint": "jshint . --exclude node_modules",
   "unit": "tape test/*",
   "test": "npm run lint && npm run unit"
 },

Dans cet exemple, les taches lint et unit sont des taches personnalisées. Elles ne font que lancer jshint et tape avec les bons arguments.

Pour lancer une tache il suffit de faire :


> npm run lint

Et si on utilise une tache proposée par npm


> npm test

On le comprend facilement, la tache test va enchaîner les deux taches lint et unit .

En résumé, si l’action est déjà proposée par npm, il faut de taper la commande npm [tache] sinon dans le cas d’une tache personnalisée, il faut rajouter run devant la tache.

Enfin, la commande run-script permet d’établir le listing des taches disponibles sur le projet.

Too easy

Ces utilitaires sont souvent des exécutables que l’on serait tenter d’installer globalement pour y accéder plus facilement. Par exemple installé localement il faudra exécuter /node_modules/.bin/jshint

Ce qui est très intéressant lorsqu’on utilise npm pour lancer ces outils depuis les scripts c’est qu’il va résoudre automatiquement le path local.

npm résout le path des modules installés localement, il n’y a plus de raison de faire des installations globales

En plus de chaîner les commandes, vous pouvez aussi les piper avec | et les lancer en parallèle avec & . Comme un bash finalement ! A noter que pour rester compatible multiplateformes et particulièrement avec windows, il est préférable de ne pas se baser sur des commandes systèmes.

Exemple d’une tache de nettoyage de dossiers où on va privilégier le paquet rimraf plutot que rm .


"scripts": {
  "clean": "rimraf ./public/* && rimraf ./dist/*"
}

Enfin, pour des taches complexes rien ne vous empêche de faire des scripts dédiés que npm se chargera de lancer, voir carrément une CLI .

Publier un module

Vous venez de créer un nouveau module révolutionnaire et vous avez peut être envie de le partager et le publier sur le dépôt public de npm. En fait, c’est très simple :

Créer son compte et s’identifier

Si vous n’avez pas encore de compte sur la plate-forme voici comment faire


npm set init.author.name "Nom"
npm set init.author.email "mail@exemple.com"

npm adduser

Dans le cas ou vous avez déjà un compte sur le site npm login  suffira.

Initialiser un projet

Comme on l’a vu dans la partie 1 de cette série sur npm , la commande npm init permet de démarrer son projet en créant le fichier package.json.

Quelques impératif à respecter pour publier :

  • Le nom du paquet ne doit pas comporter de majuscule ni commencer par un underscore ou un point
  • Une version est unique et ne peut être remplacée une fois publiée
  • L’usage des noms des modules de nodejs sont évidemment proscrit

Enfin pensez toujours à regarder si un module similaire n’existe pas déjà, soit à travers le site, soit par la commande search

Publier

Un simple npm publish suffira.

Privé ou public ?

Par défaut les commandes précédentes publieront sur le dépôt publique de npm . Néanmoins il est possible de choisir de ne pas rendre ses modules publics. Pour cela plusieurs solutions :

Et pour la suite ?

La version 3 de npm apporte de nombreux changements. Actuellement en bêta elle devrait sortir prochainement. Elle est livrée par défaut avec node depuis la V5. Parmi les principales nouveautés on peut noter :

Une refonte du système de gestion de dépendances

Actuellement lorsqu’on installe un module, npm installe avec ses dépendances de manière imbriquée. On se retrouve souvent avec des problèmes notamment sous windows puisque la longueur du path dépasse souvent la limite des 260 caractères . La gestion des dépendances est revue et devient moins profonde en fournissant l’ensemble des paquets sur le même niveau de node_modules. Les paquets avec une dépendance en commun utilisent la même. Pour les cas ou une version spéciale est demandée, alors on retrouvera l’ancien système

Responsabilité partagée

C’est un changement majeur lors du passage à la version 3. Jusqu’à présent dans les versions 1 et 2 , l’attribut peerDependencies permet de spécifier des dépendances qui seront installées automatiquement si besoin. C’est souvent le cas lorsqu’un paquet nécessite une version spécifique pour fonctionner. Désormais si la dépendance n’est pas résolue, npm générera un warning sans rien installer, ce sera au développeur de résoudre la dépendance. Ce changement est effectué dans le but de limiter les incohérences entre versions de paquets.

Cosmétique

Le changement direct le plus visible sera l’arrivée d’une barre de progression à la place du spinner actuel .

npm3 progress bar

Notes:
1. Petite exception pour brunch qui est un peu différent puisque principalement basé sur des conventions Il permet de mettre en place un profil type développement de site web très rapidement
2. d’où de nombreux comparatifs du genre grunt vs gulp
3. c’est aussi le but d’un outil de se simplifier la vie et pas l’inverse
4. make, ant, maven..sont aussi des task-runners
5. npm install avec l’option -g
6. alors que le PATH global pointe souvent vers le dossier .bin global de npm
7. npm login est un alias à npm adduser
8. Le projet Sinopia propose de mettre en place un système de ce genre sans avoir besoin de cloner la base de npmjs.org. C’est en quelque sorte un proxy pour npm
9. C’est le cas actuellement lorsqu’on utilise npm dedupen
Petite exception pour brunch qui est un peu différent puisque principalement basé sur des conventions Il permet de mettre en place un profil type développement de site web très rapidement
d’où de nombreux comparatifs du genre grunt vs gulp
c’est aussi le but d’un outil de se simplifier la vie et pas l’inverse
make, ant, maven..sont aussi des task-runners
npm install avec l’option -g
alors que le PATH global pointe souvent vers le dossier .bin global de npm
npm login est un alias à npm adduser
Le projet Sinopia propose de mettre en place un système de ce genre sans avoir besoin de cloner la base de npmjs.org. C’est en quelque sorte un proxy pour npm
C’est le cas actuellement lorsqu’on utilise npm dedupen

2 Comments

So, what do you think ?