Choisir les bons packages NPM pour votre projet

Vous avez un super projet basé sur NPM et vous savez que réinventer la roue est une mauvaise idée. Vous devez trouver le package répondant à votre besoin, mais vous en trouvez plusieurs qui font à peu près la même chose. Lequel choisir ?

Pourquoi choisir un package NPM plutôt que tout recoder ?

Avant de savoir lequel choisir, on a besoin de savoir pourquoi nous choisissons un package au lieu de coder la fonctionnalité nous même.

Grâce à un package NPM bien choisi vous profitez :

D'une fonctionnalité qui fonctionne, qui est fiable et performante, qui peut répondre à un besoin très technique
D'une documentation officielle très complète (Plus que vous ne pourrez jamais faire sur votre projet)
D'énormément de questions/réponses sur les forums comme StackOverflow
D'une mise à jour régulière du package

Pour un même besoin, un package NPM bien choisi sera toujours au dessus de vos propres composants génériques.

Choisir un package qui est populaire

Vous devez choisir un package populaire pour vous assurer de profiter des 4 avantages écrits plus haut. Pour regarder si un package est populaire, nous allons nous baser sur les étoiles de GitHub.

Les packages d'une dizaine d'étoiles au fin fond de GitHub doivent être ignorés. Voici des règles qui peuvent vous aider à faire votre choix de package :

Pour un package de framework : au minimum 20 000 étoiles
Pour un package utilitaire assez général : au minimum 1000 étoiles
Pour un package très spécifique : au minimum 200 étoiles

Voici l'exemple de 3 packages de graphiques pour Angular (le 19/05/2022) :

swimlane/ngx-charts : 4,1k étoiles sur GitHub
valor-software/ng2-charts : 2,1k étoiles sur GitHub
xieziyu/ngx-echarts : 939 étoiles sur GitHub

Choisir un package qui rattrape les populaires

Dans certains cas, il est plus judicieux de ne pas prendre le package le plus populaire. Parmi les packages disponibles, il y'a quelques fois des "challengers", plus léger, plus performant, plus facile à utiliser qui rattrapent rapidement les gros packages qui sont là depuis des années.

Pour identifier un challenger, vous pouvez utiliser https://star-history.com/ et choisir les packages que vous souhaitez comparer.

Prenons l'exemple de moment.js et de day.js, sur le papier moment.js est au dessus. Mais pourtant day.js le rattrape à toute vitesse.

Dans ce cas, même si vous n'allez avoir aucun problème avec moment.js, il n'y a pas de doute, il faut prendre day.js.

La taille du package

Parmi les packages, il peut y avoir des différences de taille dans le bundle et selon vos besoins cela peut être important.

Vous pouvez utiliser un site comme BundlePhobia pour analyser l'impact qu'aura ce package sur votre bundle.

N'hésitez pas à vérifier par vous même en ajoutant le package à votre projet pour voir l'impact réel sur votre bundle. La taille du bundle pouvant varier si vous avez importé que certains modules du package.

Utiliser un package d'une organisation réputée

Il peut être intéressant d'utiliser les packages provenant d'une organisation réputée sur votre framework. Si vous utilisez Angular créé par Google et que Google créé un package permettant de faire des graphiques sur Angular, cela peut être intéressant car on peut espérer que leurs packages s'intégreront bien.

Vous pouvez aussi retrouvé des organismes spécialisés dans le développement de package. Le groupe Valor Software est spécialisé dans les packages Angular et on peut espérer que leurs nouveaux packages, même avec peu d'étoiles, ont un très haut standard de qualité.

La simplicité d'utilisation

Il est important d'avoir un package facile à comprendre et à utiliser.

"Pff pourquoi il a choisit ce package, le code est trop complexe maintenant !"

Un Tech Lead est là pour faciliter le travail de l'équipe et la motiver. Si vous avez mis des heures à comprendre un package et que vous êtes enfin à l'aise dessus, n'oubliez pas que vous n'êtes pas seul dans l'équipe.

Vous voulez que tous les autres développeurs puissent prendre en main ce package facilement. Un trou noir dans la code base démotive les développeurs qui ne voudront plus toucher à cette partir du code.

Donc entre un package difficile à comprendre et à utiliser, et un autre qui c'est clair comme de l'eau de roche. Choisissez la simplicité, pour la productivité et le bien être de l'équipe.

Abonnez vous pour ne pas rater les nouveaux articles !