Erneutes Veröffentlichen von gimme_readme in npm mit GitHub Actions

Wie Sie oben sehen können, gibt es viele Ordner und Dateien, die für einen Benutzer (im Gegensatz zu einem Entwickler) unnötig sind. Glauben Sie beispielsweise, dass meine Benutzer möchten, dass mein Ordner „Tests“ den Code meines Programms testet? Wahrscheinlich nicht. Glauben Sie, dass meine Benutzer die Konfigurationsdateien benötigen, die zum Formatieren und Flusen meines Quellcodes erforderlich sind? Wahrscheinlich nicht. Glauben Sie, dass meine Benutzer aus einem bestimmten Grund meinen Ordner „.github“ verwenden müssten? Wahrscheinlich nicht.

Zu diesem Zweck habe ich daran gearbeitet, eine Lösung zu finden, um die Downloads eines Benutzers zu minimieren. Insbesondere möchte ich, dass sie nur über den Quellcode verfügen, der für die Ausführung meines Programms erforderlich ist.

.npmignore oder nicht .npmignore? Das ist die Frage.

Als ich darüber nachdachte, meinen Code erneut zu veröffentlichen, sprach ich auch mit meinem Freund Uday Rana über die Idee, eine .npmignore-Datei zu verwenden, um Dateien zu „ignorieren“, die ich nicht veröffentlichen wollte.

Buchstäblich direkt nachdem ich das Thema erwähnt hatte googelte Uday .npmignore und fand einen Artikel von Jeff D darüber, warum man niemals eine .npmignore-Datei verwenden sollte. Um es klarzustellen: Ich stimme Jeffs Artikel voll und ganz zu.

Im Wesentlichen besteht die Idee darin, dass wir explizit darüber sein sollten, was wir veröffentlichen wollen (Whitelisting), anstatt anzugeben, welche Dateien wir nicht veröffentlichen möchten (Blacklisting).

Mit npm ist es ganz einfach, die Dateien, die wir veröffentlichen möchten, auf die Whitelist zu setzen. Alles, was wir tun müssen, ist, unsere package.json-Datei zu bearbeiten, indem wir eine „Dateien“-Option hinzufügen, die angibt, welche Dateien wir für unser Programm veröffentlichen möchten.

Unten habe ich einen Screenshot der „files“-Option von package.json gemacht, in der es heißt: „Beim Veröffentlichen dieses Programms das Verzeichnis src/ einschließen“. Ich habe diese Änderungen inzwischen übernommen und diese Änderungen sind in meiner Version 1.0.0 meines Codes verfügbar.

HINWEIS: Bestimmte Dateien werden standardmäßig immer auf npm veröffentlicht, unabhängig davon, was Sie in Ihrer Option „Dateien“ angeben oder nicht. Wenn Sie mehr über die Verwendung der Option „Dateien“ erfahren möchten, lesen Sie die offizielle Dokumentation von npm zur Verwendung der Dateioption.

Nachdem ich meinen Code mit meiner aktualisierten package.json auf npm veröffentlicht habe, werden Benutzer, die gimme_readme installieren/neu installieren, jetzt viel weniger Blähungen auf ihren Computern haben! Sehen Sie sich den Unterschied unten an:

Hinzufügen einer GitHub-Aktion zum Veröffentlichen meines Codes in npm, wenn ich eine neue Version hinzufüge

Neben der Verbesserung der Erfahrung meiner Benutzer (indem ich den Aufwand reduziert habe, der durch die Installation von gimme_readme über npm entsteht), habe ich auch eine kontinuierliche Entwicklungspipeline (kurz CD-Pipeline) hinzugefügt, die meinen Veröffentlichungsprozess auf npm automatisiert, wenn ich eine neue Datei erstelle Veröffentlichung auf GitHub. Genaue Details dazu finden Sie im GitHub-Leitfaden zum Veröffentlichen von Node.js-Paketen. Das fühlt sich jetzt gut an, denn mit nur wenigen Klicks kann ich Code veröffentlichen, von dem ich weiß, dass er stabil ist (laut meiner CI-Pipeline), von GitHub.

Den Code für meine CD-Pipeline finden Sie hier.

Testen mit Uday

Wie ich bereits erwähnt habe, habe ich bezüglich der Tests mit meinem Freund Uday Rana zusammengearbeitet. Zum Zeitpunkt des Schreibens war er in der Lage, mein Tool zu installieren und wie folgt zu verwenden:

Für mich sieht alles gut aus und die meisten Optionen, die ich für mein Werkzeug habe, verhalten sich mehr oder weniger so, wie er es erwartet. Aber ich muss diesen Vorgang noch einmal wiederholen, da ich noch einige weitere Optimierungen hinzufügen möchte!

Die Reise endet nie ... aber das macht den Spaß aus!

Ich habe kürzlich auch von Möglichkeiten gehört, meinen Code weiter zu optimieren. Ich interessiere mich insbesondere dafür, zu lernen, wie ich meine CI- und CD-Pipelines verbessern kann, indem ich mehr über zusammengesetzte Aktionen und wiederverwendbare Workflows in Bezug auf GitHub-Aktionen erfahre. Ich hoffe, dass diese Techniken mir dabei helfen, die Menge an Code, die ich schreibe, zu reduzieren und eine Art Leistungssteigerung zu erzielen! Ich weiß noch nicht viel über diese Themen, aber Sie können wetten, dass ich wahrscheinlich bald darüber bloggen werde.

Und damit meine Freunde, schließe ich ab, worüber ich in diesem Blog sprechen wollte.

Bis zum nächsten Mal!