Choisir les bonnes dépendances : un guide pratique complet

Si vous étiez chef dans un restaurant haut de gamme étoilé au Michelin, achèteriez-vous des légumes et de la viande provenant de sources aléatoires non vérifiées ? Le coût de presque n'importe quel projet moyen se mesure en centaines de milliers, voire en millions de dollars. Je crois que notre industrie devrait avoir la même approche que les restaurants.

Première question à se poser tout de suite : avez-vous vraiment besoin d'une nouvelle dépendance ? Le problème pourrait-il être résolu en utilisant l'environnement actuel, tel que la langue ou les bibliothèques installées ? Par exemple, il n'est pas nécessaire d'installer une bibliothèque supplémentaire pour générer des UUID. Node.js et les navigateurs le prennent en charge immédiatement : crypto.randomUUID()

La deuxième question : avez-vous besoin de toute la bibliothèque ? Par exemple, si vous n'avez besoin que d'une liste déroulante, cela vaut-il la peine d'installer quelque chose comme Bootstrap ? Peut-être vaut-il mieux se limiter à une seule bibliothèque ciblée avec un composant déroulant sans style de Radix UI ?

D'accord. Nous avons quelques candidats en tête. Alors, comment choisir le bon ?

Un fichier README magnifiquement formaté ? Un nom bien connu ? Plus de forks, d'étoiles et de téléchargements que d'autres ? Malheureusement, ces facteurs seuls ne suffisent pas. Ici, nous sélectionnons un fournisseur de services. Nous voulons que tous les problèmes qui surviennent soient résolus rapidement, que les fonctionnalités restent à jour et, surtout, que le service soit sûr et fiable. Des métriques externes simples n'indiquent pas toujours la qualité ou l'adéquation à long terme. Avant d'installer ce que nous avons trouvé sur le catalogue du référentiel, il serait bon de visiter le référentiel GitHub et d'analyser son contenu.

J'ai préparé une liste de critères que j'utilise depuis quelques années. J'espère qu'ils vous aideront à choisir les bibliothèques les plus appropriées. Il est essentiel de les considérer de manière globale et, dans certains cas, de faire des compromis lors du choix entre eux.

Avis de non-responsabilité : Je ne critique pas les bibliothèques mentionnées ci-dessous ni n'essaie de décourager leur utilisation. Dans certains cas, j'ai intentionnellement omis des noms pour me concentrer sur l'exemple de critère tout en maintenant l'exactitude factuelle.

1. Sécurité

Est-il sûr à utiliser ? Cela peut ressembler à de la fiction, mais oui, les dépendances peuvent être dangereuses. Par exemple, une fonctionnalité intéressante a été ajoutée à une bibliothèque avec 500 000 téléchargements : elle essaie de remplacer tous les fichiers de l'ordinateur par ❤️ si votre adresse IP se situe dans une plage spécifique.

Un fait intéressant est que cette dépendance a été utilisée dans vue-cli . Comment pouvons-nous découvrir de tels problèmes? Consultez la page des problèmes ou essayez de googler par le nom de la bibliothèque. Habituellement, ces informations font surface rapidement.

2. Entretien

À quand remonte la dernière version ? À quelle fréquence les versions se produisent-elles ? Les versions régulières garantissent que les problèmes sont résolus et les mises à jour prennent en charge les technologies en constante évolution. Dans le cadre du développement mobile, des versions régulières garantissent également que le projet se compile avec succès.

Voici un exemple tiré du monde du Go : les auteurs d'une bibliothèque comptant 18 200 étoiles ont décidé d'arrêter de maintenir leur dépendance et l'ont archivée. Cela signifie que, dans quelques années, le manque de support et de mises à jour deviendra un problème. Imaginez maintenant installer une dépendance similaire sans vérifier d'abord GitHub. C'est en quelque sorte vérifier la date de péremption des produits.

Voici un exemple de bonnes versions fréquentes :

3. Problèmes ouverts / fermés

1. Quel est le rapport entre les problèmes ouverts et les problèmes résolus ? Dans quelle mesure les auteurs sont-ils disposés à accepter des changements ? Il est possible que vous ayez besoin de contribuer quelque chose un jour. Par exemple, cette bibliothèque est assez populaire et a un pourcentage de 98% de problèmes fermés. Seuls 18 sont ouverts.

   

   
   

2. À quelle vitesse les problèmes critiques sont-ils résolus ? Une fois, j'ai choisi un ORM avec 31k étoiles, mais à un moment donné, nous avons rencontré un problème qui nous a bloqué. Nous avons dû chercher des solutions de contournement et éventuellement passer à une autre solution. Malheureusement, près de quatre ans se sont écoulés et le problème n'est toujours pas résolu.

   

   Ces problèmes peuvent être identifiés en triant par les plus commentés.

   
   

3. Le processus de contribution a-t-il été organisé par les créateurs ? Existe-t-il un flux de travail clair et défini ? Par exemple, les créateurs de Next.js ont même enregistré une vidéo de 40 minutes sur leur processus de contribution.

   
   

4. Qualité des codes

Oui, il peut y avoir beaucoup de code, mais il est toujours possible d'examiner ses différentes parties. Comment le projet est-il organisé ? Est-il compréhensible et bien structuré, et les bonnes pratiques s'appliquent-elles ? Plus le code est écrit de manière médiocre, plus la probabilité de disparition du projet à l'avenir est élevée. Beaucoup de petits candidats ont été éliminés à ce stade pour moi.

5. Couverture des tests

La bibliothèque a-t-elle des tests ? Quelle est la couverture des tests ? Comment les épreuves ont-elles été rédigées ? Même si les responsables examinent les demandes de fusion, il est possible que quelque chose soit oublié. Il y a beaucoup de personnes différentes qui contribuent à la bibliothèque. Normalement, les informations sur la couverture des tests sont affichées sur des badges en haut du référentiel. Cependant, si ce n'est pas le cas, nous pouvons toujours rechercher des tests dans le projet. Par exemple, la famille de bibliothèques formatjs a une excellente couverture de test et comprend différents types de tests.

6. Taille de la bibliothèque

Les applications mobiles ont souvent de grandes tailles de dépendance et l'ensemble de l'application peut même dépasser 200 Mo, ce qui peut entraîner des problèmes lors des téléchargements sur le réseau cellulaire et consommer beaucoup d'espace de stockage. Cela est particulièrement problématique pour les applications CSR frontales, où des vitesses Internet lentes peuvent augmenter considérablement les temps de chargement.

Pour les projets Web, il existe un excellent outil pour déterminer la taille des packages : https://bundlephobia.com . Bien sûr, le rendu côté serveur et le tree shaking peuvent réduire la taille, mais cela doit toujours être vérifié.

Un exemple populaire est les bibliothèques de manipulation de date. La fonctionnalité fournie par dayjs (2,9 Ko) peut être suffisante, éliminant ainsi le besoin d'installer moment.js (72,1 Ko) ou date-fns (26,8 Ko).

7. Nombre de dépendances

Tous les points énumérés ci-dessus sont multipliés, dans une certaine mesure, par le nombre de dépendances dans l'ensemble de l'arborescence des dépendances du projet. Un excellent outil pour vérifier l'arborescence complète des dépendances : https://npm.anvaka.com

8. Licence

Avez-vous déjà pensé à cela? Moi non plus. Par exemple, les licences MIT et Apache 2.0 permettent l'utilisation gratuite de bibliothèques dans des projets commerciaux, tandis que certaines licences GPL v2 ont des exigences et des restrictions spécifiques. Dans l'un de nos projets, nous avions un tableau préparé par un avocat pour vérifier toutes les licences de notre arbre de dépendance. Donc, si vous voyez quelque chose d'inhabituel dans une licence, mieux vaut consulter un avocat pour éviter les problèmes lors d'une vérification. Nous pouvons extraire toutes les licences des dépendances npm existantes à l'aide de l'utilitaire legal . PS Je ne suis pas avocat, et ce n'était pas un avis juridique. C'est un cas rare et spécialisé où quelque chose pourrait ne pas convenir en raison de la licence, mais c'est toujours possible.

La fin!

Merci d'avoir lu mon article! Le point clé était de montrer des exemples concrets qu'une prise de décision superficielle et rapide peut parfois ne pas conduire à la meilleure option. En tenant compte de ces critères, vous serez en mesure de prendre une décision plus éclairée.

N'hésitez pas à laisser vos commentaires ou suggestions. N'hésitez pas également à partager votre expérience dans les commentaires. Vos likes et commentaires m'inspirent pour écrire de nouveaux articles. Bonne cuisine :)