Für das Labor dieser Woche werde ich jetzt GENEREADME veröffentlichen.
Beiträge zu GENEREADME sind willkommen! Bitte schauen Sie sich CONTRIBUTING.md an, um Richtlinien zum Einrichten der Umgebung, zum Ausführen und Testen des Tools und zum Einreichen von Änderungen zu erhalten.
GENEREADME ist ein Befehlszeilentool, das eine Datei aufnimmt, verarbeitet und eine README-Datei mit einer Erklärung oder Dokumentation des Inhalts der Datei generiert. Das Tool nutzt die OpenAI-Chat-Vervollständigung, um die Datei zu analysieren und Inhalte zu generieren.
Installierendas Tool, indem Sie den folgenden Befehl ausführen:
npm i -g genereadme
Das Tool unterstützt derzeit Groq und OpenRouter, das standardmäßig Groq verwendet. Es muss ein gültiger API-Schlüssel für den entsprechenden Anbieter bereitgestellt werden.
Geben Sie einen gültigen API-Schlüssel an, indem Sie entweder eine .env-Datei erstellen oder das Flag -a oder --api-key verwenden, wenn Sie den folgenden Befehl verwenden:
API_KEY=API_KEY or genereadme <files> -a API_KEY genereadme <files> --api-key API_KEY
Führen Sie das Tool mit den vorhandenen Beispieldateien aus oder beginnen Sie mit der Verwendung Ihrer eigenen:
Die Veröffentlichung des Tools selbst war überhaupt kein Problem, allerdings musste ich einige zusätzliche Schritte unternehmen, um eine ordnungsgemäße Veröffentlichung sicherzustellen.
Bevor ich mich auf den Veröffentlichungsprozess konzentrierte, nahm ich mir etwas Zeit, um Best Practices und Schritte zum Veröffentlichen eines Pakets in der npm-Registrierung zu recherchieren. Folgendes habe ich gelernt:
1. So veröffentlichen Sie ein Paket in npm
Um den grundlegenden Prozess zu verstehen, habe ich auf die offizielle npm-Dokumentation verwiesen. Dieses Handbuch bietet einen Überblick über wesentliche Schritte, einschließlich der Einrichtung einer package.json, der Ausführung von npm Publish und der Verwaltung von Versionen.
2. Verwendung semantischer Versionierung
Die Versionierung spielt eine entscheidende Rolle bei der Signalisierung von Änderungen an Benutzer. Ich habe mir die Prinzipien der semantischen Versionierung angesehen, die das MAJOR.MINOR.PATCH-Format verwendet, um wichtige Änderungen, neue Funktionen und Fehlerbehebungen zu beschreiben. Dadurch wurde sichergestellt, dass mein Tool für jede Version eine aussagekräftige Versionsnummer hatte.
3. Verwalten von .npmignore
Ich habe recherchiert, wie ich die .npmignore-Datei effektiv nutzen kann, um sicherzustellen, dass mein npm-Paket nur die für Endbenutzer erforderlichen Dateien enthält. Durch die sorgfältige Erstellung dieser Datei konnte ich entwicklungsspezifische Dateien wie Konfigurationsdateien, Tests und Dokumentation ausschließen, die im veröffentlichten Paket nicht erforderlich sind. Dies reduzierte nicht nur die Größe des Pakets, sondern machte es auch professioneller, indem es sich ausschließlich auf das konzentrierte, was die Benutzer tatsächlich zum Ausführen des Tools benötigen. Die ordnungsgemäße Verwaltung von .npmignore ist ein entscheidender Schritt bei der Vorbereitung einer ausgefeilten Version.
Nachdem ich meine Recherche durchgeführt hatte, überprüfte ich noch einmal alle Anforderungen, mögliche Fehler und alle fehlgeschlagenen Tests.
Nachdem für mich alles gut aussah, habe ich das Paket veröffentlicht, indem ich Folgendes ausgeführt habe:
npm i -g genereadme
HINWEIS: Für die Ausführung dieses Befehls muss der Benutzer bei seinem npm-Konto angemeldet sein, indem er den folgenden Befehl ausführt:
API_KEY=API_KEY or genereadme <files> -a API_KEY genereadme <files> --api-key API_KEY
Nachdem ich Version 1.0.0 von GENEREADME veröffentlicht habe, war es an der Zeit, einige Endbenutzer zu bitten, zu testen, ob das Paket funktioniert.
Wie erwartet gab es ein paar Fehler, die es geschafft haben. Eines, das die Leistung des Werkzeugs nicht beeinträchtigt, und eines, das es tatsächlich kaputt macht.
Der einfache Fehler, der gefunden wurde, betrifft die Verwendung des Befehls genereadme -v. Dieser Befehl sollte den Namen des Tools und die aktuelle Version ausgeben. Ich habe diesen Teil jedoch so codiert, dass ich den Projektnamen und die Version aus package.json im aktuellen Verzeichnis abrufe. Das bedeutet, dass, wenn ein Endbenutzer diesen Befehl ausführt, der Name und die Version von IHREM Projekt anstelle meines angezeigt werden. Dies war also eine einfache Lösung, um sicherzustellen, dass es immer aus dem richtigen Projekt abgerufen wird.
Das hier ist ein Fehler, der das Tool kaputt macht, das in meinen lokalen Tests technisch funktioniert hat, aber ich habe einen einfachen Testfall vergessen.
Die Ordnerstruktur des Projekts war nur an Entwickler und Mitwirkende gedacht, daher wird erwartet, dass der Ordner „Ausgaben“ im Projekt vorhanden ist, den ich auch in das Haupt-Repository verschoben habe, das ein Beispielergebnis einer Ausgabe enthält.
Nun musste ich bedenken, dass es für den Endbenutzer etwas anders sein wird.
Zuvor wurde der Code so geschrieben, dass er einfach in das Verzeichnis „outputs/“ schreibt, ohne zu prüfen, ob es vorhanden ist, und eins zu erstellen, wenn dies nicht der Fall ist. Dies führte dazu, dass das manuelle Testen des veröffentlichten Pakets fehlschlug, da der Endbenutzer kein Outputs/-Verzeichnis hatte. Das Tool schlägt einfach fehl, anstatt eines zu erstellen, wenn es nicht existiert.
Nach dieser Entdeckung dachte ich, ziemlich einfach, oder?
Bis ich versuchte, die Änderungen voranzutreiben und dachte: „Okay, das behebt das Problem!“ aber zu meiner Überraschung versagte mein CI!
Der Schuldige:
npm i -g genereadme
So überprüfe und erstelle ich das Verzeichnis „outputs/“. Allerdings habe ich in meinen End-to-End-Tests fs.existsSync() aus folgendem Grund dazu verspottet, den Wert „false“ zurückzugeben:
API_KEY=API_KEY or genereadme <files> -a API_KEY genereadme <files> --api-key API_KEY
Diese Funktion sucht nach einer Toml-Konfigurationsdatei, die fs.existsSync() verwendet, und ich wollte für meine End-to-End-Tests keine Toml-Konfigurationsdatei verwenden. Ich habe diese Methode so simuliert, dass sie „false“ zurückgibt, was jetzt der Fall ist steht im Widerspruch zu dem Bugfix, den ich durchgeführt habe.
Ich muss das Verspotten noch beherrschen und Möglichkeiten finden, möglicherweise unterschiedliche Scheinwerte für dieselbe Methode unter verschiedenen Bedingungen zu erstellen. Bis ich dieses Verfahren erlerne, habe ich die vorübergehende Korrektur vorgenommen, um sicherzustellen, dass das Verzeichnis „outputs/“ vor jedem Testfall entfernt wird.
npm publish
Und damit sind die wichtigen Patches abgeschlossen, die ich gemacht habe! GENEREADME ist jetzt verfügbar!
Das obige ist der detaillierte Inhalt vonVeröffentlichung von GENEREADME. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!