:::: MENU ::::

Tout savoir sur la nouvelle version de npm : npm 5

Il vient de sortir, prêt à temps pour la nouvelle LTS de node (node 8) : npm 5. Il s’agit d’une évolution importante du célèbre gestionnaire de paquet, voyons ensemble les principales nouveautés.

Performances

Depuis l’arrivée de npm3 , de nombreux utilisateurs se plaignent de la performance de npm. Le cas arrive d’autant plus souvent puisque la philosophie des dépendances JavaScript tend vers celle d’unix où une seule fonction peut devenir un paquet… Pour palier à ce problème des parties fondamentales de npm sont réécrites pour améliorer l’ensemble du système.

Ainsi sont nés cacache et pacote qui permettent de gérer le cache et le système de récupération des métadonnées des paquets. L’amélioration est nette et les installations de 2 à 5 fois plus rapides qu’avec npm4. Si il semble que yarn reste encore plus véloce pour le moment, les différences avec la v4 sont néanmoins flagrantes.

A noter aussi qu’une installation d’une dépendance locale se fait désormais par un lien symbolique plutôt qu’une installation complète, cela devrait amener un gain de performance non négligeable

Fiabilité

La réécriture du système de cache et de l’architecture générale n’apporte pas seulement des performances mais aussi une bien meilleure stabilité lors des installations.

Le projet yarn à été créé partant du constat que npm ne garantissait pas la reproductabilité parfaite d’une installation. Pour améliorer ce point critique, npm 5 fixe désormais les versions des paquets par défaut et automatiquement dans un nouveau fichier package-lock.json. Chaque installation de paquet implique une inscription comme dépendance au projet.

La réécriture du système de cache permet aussi un algorithme de hash plus fort pour les vérifications de sommes de contrôle et propose une très forte tolérance aux erreurs d’intégrité

Pour résumer

  • package-lock.json = shrinkwrap.json automatique
  • le –save par défaut sur chaque installation
  • meilleur fiabilité du cache

Des features

En plus d’avoir corrigé de nombreux bugs existants, npm 5 apporte un lot de fonctionnalités intéressantes comme des possibilités d’utilisation hors-ligne, un nouveau niveau de log notice ou encore une indentation du fichier package.json préservée après une mise à jour.

Illustration du mode offline

Dès la première installation, on constate une différence visuelle importante puisque le log d’installation est désormais résumé
$ npm install
npm added 125, removed 32, updated 148 and moved 5 packages in 5.032s.

Enfin, les dépendances qui utilisent des projets git où les commits sont tagués en semver sont prises en compte avec le même système qu’un paquet npm. Cela permet ce genre d’écriture :

"dependencies": {
  "project": "git://github.com/user/project.git#^1.0.0"
}

 

Comment installer npm 5

Deux options : attendre l’arrivée imminente de la prochaine version de node, node 8 LTS qui embarquera npm 5 par défaut ou bien installer manuellement npm 5 à l’aide de…npm. Pour cela rien de plus simple

npm i -g npm@5

 

J’ai pas compris la différence entre package-lock.json et shrinkwrap.json ?

La nuance est subtile c’est vrai. Le contenu des deux fichiers est le même mais leur but est différent.

package-lock.json est à destination des développeurs uniquement, il ne sera jamais publié sur le registre, par contre il est recommandé de le versionner avec son projet. Sa création est automatique .

shrinkwarp.json permet lui aussi de fixer toutes les dépendances mais peut être publié. Cela permet de rester strict au besoin, et surtout c’est comme cela que npm fonctionne actuellement. Il n’est pas utile de versionner shrinkwrap.json si package-lock.json l’est déjà.

Fun fact

La licence de npm est de type Artistic-2.0

Aller plus loin

Pour ce qui est des workflow et commandes de base, rien ne change , n’hésitez pas à aller faire un tour sur mes articles consacrés à npm


2 Comments

  • Répondre Jérémy |

    Dans Yarn on a un yarn.lock, qui nous permet de connaître précisément la version (et même le hash commit) pour un tel paquet que l’on utilise (comme le fait composer) au moment du déploiement par exemple.
    Je me souviens que le shrinkwrap.json lui était plus « souple » et permettait d’avoir des « ranges » de versions qui sont « ok ». (évidemment si un mainteneur de paquet respecte pas le semver… on est pas dans la m*****)

    Est ce que ce nouveau « package-lock.json » bloque réellement sur une version précise ?

  • Répondre admin |

    Voici la spec concernant le fichier package-json.lock et plus précisément la partie concernant la version : https://github.com/npm/npm/blob/link-specifier/doc/files/package-lock.json.md#version-1

    Chaque version est identifiée précisément, par exemple avec l’url qui permet de retrouver le paquet. Il est donc possible d’avoir un hash de commit comme yarn.

    Les fichiers package-lock.json et yarn.lock sont du coup assez similaires.

    npm 5 rajoute en plus un hash de contrôle pour vérifier l’intégrité ( et je pense que c’est la qu’il prend un plus plus de temps que yarn au niveau des installations )

So, what do you think ?