Premiers soins pour les dépendances JavaScript brisées

J'aimerais écrire sur JavaScript dépendances. Mais commençons par le commencement. Si vous êtes développeur de logiciels, vous savez probablement déjà que l'un de vos nombreux rôles n'est certainement pas d'être un énième inventeur de roues. Du moins, pas dans la plupart des cas. Le monde a suffisamment évolué pour qu'il existe aujourd'hui des progiciels pour presque tout, ce qui rend notre développement plus facile et plus efficace.

Bien entendu, il ne s'agit pas de se désintéresser des autres questions - chaque paquet dispose d'un large espace pour s'améliorer et évoluer. Cependant, l'objectif de votre entreprise est d'apporter un service complet à vos clients. produit sur un plateau juste à temps ou même avant qu'il ne soit levé. Les emballages vous aideront à réaliser ces projets, en apportant npm ou fil sur la liste de vos meilleurs amis, mais attention : toute solution, y compris celle-ci, peut également comporter des risques. Nous allons tenter de le décrire et de vous montrer une meilleure façon de vous en sortir dans l'article ci-dessous.

Commençons par une histoire...

Imaginez un grand JavaScript projet. Les exigences de l'entreprise obligent les développeurs à utiliser un paquetage spécifique, permettant une intégration correcte avec un autre système du client. Et c'est tout à fait normal. MVP a été apportée dans les délais, le contrat suivant a été signé et le développement se poursuit. Le client demande à intégrer la partie suivante d'un système, ce qui nécessite la mise à jour de votre paquet.

Cette partie se passe bien, jusqu'à ce que les tests soient lancés. Il semble que le paquet contienne un bogue simple, mais gênant, qui n'a encore été corrigé dans aucune version du produit et on sait que cela n'arrivera pas assez tôt. Vous ne pouvez pas vous contenter de réparer votre node_modules répertoire - il devrait être supprimé de votre dépôt, ce qui signifie que vos collaborateurs ne sauront jamais rien de vos changements ! Pendant que vous lisiez ces lignes, vous avez probablement déjà compris ce qu'il fallait faire - fork. Mais avez-vous vraiment besoin d'un tel marteau ?

Comprendre votre problème

Vous devez savoir si le problème auquel vous êtes confronté ne concerne que vous ou une communauté plus large. Parfois, les gens interprètent l'absence de certaines fonctionnalités comme un bogue, ce qui n'est pas toujours correct. C'est pourquoi, votre solution peut ne pas être acceptée par une communauté et ne pas être incluse dans un référentiel officiel. Cependant, vous en avez toujours besoin ici et maintenant. Eh bien, il faut le rafistoler !

D'après les notes de version du dépôt github, le patch-package ) est sorti officiellement en mai 2017. It est un outil puissant, qui permet d'installer les modifications à l'intérieur d'un projet de dépendance dans votre système d'information. node_modules répertoire. Certains diront qu'il s'agit là d'une véritable folie - la commande d'installation de votre gestionnaire de dépendances écrasera les modifications.

C'est exact. Cependant, un patch-package coexiste avec npm et fil parfaitement (je dois admettre qu'il fonctionne légèrement mieux avec npm jusqu'à présent, vous pouvez en savoir plus dans la section "Why you should use postinstall-prepare with Yarn ?" du fichier README) et tire pleinement parti d'une préparation par script ("script" : { "prepare" :""}) de vos package.json fichier. Patch-package crée littéralement un répertoire de différences entre vos modifications et le paquet original, stocké dans le dossier patch de votre projet actuel..

Après avoir exécuté la commande d'installation et téléchargé toutes les dépendances, il applique cette différence au répertoire du projet, en faisant une reconstruction parfaite de vos changements pour tous les collaborateurs. Cela vous simplifie la vie, n'est-ce pas ? Cette solution présente également quelques inconvénients. Le paquet de correctifs ne peut pas corriger les dépendances de votre paquet ou faire des changements dans package.json.

Dans ce cas, vous pouvez utiliser la solution de la fourche. Vous devez également prendre en compte le nombre de modifications que vous êtes sur le point d'appliquer à votre paquet de dépendances et si elles vont croître avec le temps. Si c'est le cas, vous devez réfléchir attentivement avant d'utiliser la solution fork, car il s'agit d'un projet qui vous appartient.

Ne soyez pas égoïste !

Le patch est un excellent moyen de corriger vos dépendances sans créer des forks sans fin et sans générer de multiples sources de projet. Mais vous devez toujours vous rappeler que profiter de la communauté ne doit pas être unidirectionnel. Si vous trouvez un bogue ou si vous pensez pouvoir améliorer le paquet que vous utilisez, vous devriez toujours envisager d'aider les autres en enregistrant un problème ou même en contribuant au projet !