Republier gimme_readme sur npm avec GitHub Actions

Cette semaine, dans mon cours Open Source, mes camarades de classe et moi avons été chargés de publier chacun de nos propres programmes dans un registre de packages.

Quand vous entendez quelqu'un dire registre de code, registre de packages ou registre, j'aime penser à ces mots comme représentant un endroit où les développeurs et les entreprises publient leur code pour que d'autres puissent le télécharger. Pour une description plus précise, vous pouvez lire cet article de Mozilla :

Bases de la gestion des packages - Apprendre le développement Web | MDN

Cela nous amène à la fin de notre tournée des gestionnaires de packages. Notre prochaine étape consiste à créer un exemple de chaîne d'outils, mettant en pratique tout ce que nous avons appris jusqu'à présent.

donne-moi_readme - npm

gimme_readme est un outil de ligne de commande alimenté par l'IA qui génère un fichier README.md complet pour votre projet. Il analyse plusieurs fichiers de code source à la fois, fournissant des explications concises sur l'objectif, les fonctionnalités et les composants clés de chaque fichier. Dernière version : 1.0.0, dernière publication : il y a 16 heures. Commencez à utiliser gimme_readme dans votre projet en exécutant `npm i gimme_readme`. Il n'y a aucun autre projet dans le registre npm utilisant gimme_readme.

Comme vous pouvez le voir ci-dessus, il existe de nombreux dossiers et fichiers qui ne sont pas nécessaires à un utilisateur (par opposition à un développeur). Par exemple, pensez-vous que mes utilisateurs souhaiteraient que mon dossier « tests » teste le code de mon programme ? Probablement pas. Pensez-vous que mes utilisateurs ont besoin des fichiers de configuration nécessaires pour formater et pelucher mon code source ? Probablement pas. Pensez-vous que mes utilisateurs auraient besoin d'utiliser mon dossier « .github » pour une raison particulière ? Probablement pas.

À cette fin, j'ai travaillé pour trouver une solution pour minimiser ce qui est téléchargé par un utilisateur ; plus précisément, je veux qu'ils n'aient que le code source nécessaire au fonctionnement de mon programme.

Vers .npmignore ou pas .npmignore ? C'est la question.

Alors que je pensais republier mon code, je discutais également avec mon ami Uday Rana, de l'idée d'utiliser un fichier .npmignore pour "ignorer" les fichiers que je ne voulais pas publier.

Littéralement juste après avoir mentionné le sujet, Uday a recherché .npmignore sur Google et a trouvé un article écrit par Jeff D expliquant pourquoi il ne faut jamais utiliser un fichier .npmignore. Pour être clair, je suis entièrement d’accord avec l’article de Jeff.

Essentiellement, l'idée est que nous devrions être explicites avec ce que nous voulons publier (liste blanche), au lieu d'indiquer quels fichiers nous ne voulons pas souhaitez publier (liste noire).

Mettre en liste blanche les fichiers que nous souhaitons publier est simple avec npm. Tout ce que nous avons à faire est de modifier notre fichier package.json en ajoutant une option "files", qui indique les fichiers que nous souhaitons publier pour notre programme.

Ci-dessous, j'ai pris une capture d'écran de l'option "files" de package.json, qui indique "inclure le répertoire src/ lors de la publication de ce programme". Depuis, j'ai validé ces modifications et ces modifications sont disponibles dans ma version v1.0.0 de mon code.

REMARQUE : Certains fichiers par défaut sont toujours publiés sur npm, peu importe ce que vous spécifiez ou ne spécifiez pas dans votre option "fichiers". Si vous souhaitez en savoir plus sur l'utilisation de l'option "files", consultez la documentation officielle de npm sur la façon d'utiliser l'option file.

Après avoir publié mon code sur npm avec mon package.json mis à jour, les utilisateurs qui installent/réinstallent gimme_readme auront désormais beaucoup moins de surcharge sur leurs ordinateurs ! Voyez la différence ci-dessous :

Ajout d'une action GitHub pour publier mon code sur npm lorsque j'ajoute une nouvelle version

En plus d'améliorer l'expérience de mes utilisateurs (en réduisant la surcharge liée à l'installation de gimme_readme via npm), j'ai également ajouté un pipeline de développement continu (pipeline cd en abrégé) qui automatisait mon processus de publication sur npm lorsque je crée un nouveau sortie sur GitHub. Pour plus de détails sur la façon de procéder, vous pouvez vous référer au guide des packages Publishing Node.js de GitHub. Cela fait du bien maintenant, car en un clic de quelques boutons, je suis capable de publier du code que je sais stable (selon mon pipeline CI), à partir de GitHub.

Vous pouvez trouver le code de mon pipeline de cd ici.

Tester avec Uday

Comme je l'ai mentionné plus tôt, je travaillais avec mon ami Uday Rana en ce qui concerne les tests. Au moment de la rédaction de cet article, il a pu installer mon outil, et l'utiliser comme ceci :

Les choses me semblent bonnes, et la plupart des options dont je dispose pour mon outil se comportent plus ou moins comme il l'attend. Mais je vais devoir répéter ce processus à nouveau, car j'ai d'autres optimisations que je souhaite ajouter !

Le voyage ne se termine jamais... mais c'est ce qui le rend amusant !

J'ai également récemment entendu parler de moyens d'optimiser davantage mon code. En particulier, je m'investis dans l'apprentissage de la façon d'améliorer mes pipelines CI et CD en découvrant les actions composites et les flux de travail réutilisables en ce qui concerne les actions GitHub. J'espère que ces techniques m'aideront à réduire la quantité de code que j'écris et offriront une sorte d'amélioration des performances ! Je ne connais pas encore grand chose sur ces sujets, mais vous pouvez être sûr que je bloguerai probablement bientôt sur ce sujet.

Et ça mes amis, conclut ce dont je voulais parler dans ce blog.

À la prochaine fois !

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!