今週のラボでは、GENEREADME をリリースする予定です。
クレオブントラ
/
ジェネリードミー
GENEREADME への貢献は大歓迎です!環境のセットアップ、ツールの実行とテストの方法、変更の送信に関するガイドラインについては、CONTRIBUTING.md を確認してください。
GENEREADME は、ファイルを取り込んで処理し、ファイルの内容の説明やドキュメントを含む README ファイルを生成するコマンドライン ツールです。このツールは OpenAI チャット補完を利用してファイルを分析し、コンテンツを生成します。
インストールします:
npm i -g genereadme
このツールは現在、Groq と OpenRouter をサポートしており、デフォルトで Groq を使用します。適切なプロバイダーの有効な API キーを指定する必要があります。
.env ファイルを作成するか、コマンドの使用時に -a または --api-key フラグを使用して、有効な API キーを指定します。
API_KEY=API_KEY or genereadme <files> -a API_KEY genereadme <files> --api-key API_KEY
既存のサンプル ファイルを使用してツールを実行するか、独自のサンプル ファイルを使用して開始します。
ツールの公開自体はまったく問題ありませんでしたが、適切なリリースを確実にするためにいくつかの追加手順を実行する必要がありました。
リリース プロセスに焦点を当てる前に、npm レジストリにパッケージを公開するためのベスト プラクティスと手順を調査するのに時間を費やしました。私が学んだことは次のとおりです:
1.パッケージを npm に公開する方法
基本的なプロセスを理解するために、npm の公式ドキュメントを参照しました。このガイドでは、package.json のセットアップ、npm public の実行、バージョンの管理など、重要な手順の概要を説明しました。
2.セマンティック バージョニングの使用
バージョン管理は、変更をユーザーに通知する上で重要な役割を果たします。セマンティック バージョニングの原則を調べました。セマンティック バージョニングでは、重大な変更、新機能、バグ修正を記述するために MAJOR.MINOR.PATCH 形式を使用します。これにより、私のツールにはリリースごとに意味のあるバージョン番号が付けられるようになりました。
3. .npmignore
の管理
.npmignore ファイルを効果的に使用して、npm パッケージにエンドユーザーに必要なファイルのみが含まれていることを確認する方法を調査しました。このファイルを慎重に作成することで、構成ファイル、テスト、ドキュメントなど、公開されたパッケージに必要のない開発固有のファイルを除外することができました。これにより、パッケージのサイズが縮小されただけでなく、ユーザーがツールを実行するために実際に必要なものだけに焦点を当て、パッケージがよりプロフェッショナルなものになりました。 .npmignore を適切に管理することは、洗練されたリリースを準備するための重要なステップです。
調査を行った後、要件、考えられるバグ、失敗したテストがないか再確認しました。
すべてが順調に見えたので、次のコマンドを実行してパッケージの公開を開始しました。
npm i -g genereadme
注: このコマンドを実行するには、次のコマンドを実行してユーザーが npm アカウントにログインする必要があります:
API_KEY=API_KEY or genereadme <files> -a API_KEY genereadme <files> --api-key API_KEY
GENEREADME v1.0.0 を公開したので、一部のエンドユーザーにパッケージが機能するかどうかのテストを依頼するときが来ました。
予想通り、いくつかのバグがありましたが、問題は解決しました。ツールの動作に影響を与えないものと、実際にツールを破壊するものがあります。
見つかった単純なバグは、genereadme -v コマンドの使用に関するものです。このコマンドは、ツールの名前と現在のバージョンを出力する必要があります。ただし、この部分をコーディングした方法では、現在のディレクトリの package.json からプロジェクト名とバージョンを取得します。これは、エンドユーザーがこのコマンドを実行すると、私のプロジェクトではなく、彼ら プロジェクトの名前とバージョンが表示されることを意味します。したがって、これは、常に正しいプロジェクトから取得されるようにするための簡単な修正です。
これは、ローカル テストでは技術的に動作していたツールを壊すバグですが、簡単なテスト ケースを忘れていました。
プロジェクトのフォルダー構造は開発者と貢献者のみを念頭に置いていたため、プロジェクト内に出力フォルダーがあることが想定されており、出力のサンプル結果を含むメイン リポジトリにもプッシュしました。
ここで、エンドユーザーにとっては少し異なることに留意する必要がありました。
以前のコードは、outputs/ ディレクトリの存在をチェックせずに単にそのディレクトリに書き込み、存在しない場合はそれを作成するように書かれていました。これにより、エンドユーザーに出力/ディレクトリがなかったため、公開されたパッケージの手動テストが失敗しました。ツールは、ディレクトリが存在しない場合、ディレクトリを作成せずに失敗するだけです。
この発見の後、私は非常に単純に考えましたね?
「よし、これで直った！」と思って変更をプッシュしようとするまでは。しかし驚いたことに、私の CI は失敗しました!
犯人:
npm i -g genereadme
これが、outputs/ ディレクトリを確認して作成する方法です。ただし、エンドツーエンドのテストでは、次の理由から fs.existsSync() をモックして false の値を返していました。
API_KEY=API_KEY or genereadme <files> -a API_KEY genereadme <files> --api-key API_KEY
この関数は、fs.existsSync() を使用する toml 構成ファイルをチェックします。エンドツーエンドのテストには toml 構成ファイルを使用したくなかったので、このメソッドをモックして false を返しました。私が行ったバグ修正と競合しています。
私はまだモックをマスターしておらず、異なる条件に対して同じメソッドに対して異なるモック値を作成する方法を見つけていません。そのため、その手順を習得するまで、すべてのテスト ケースの前に、outputs/ ディレクトリが確実に削除されるように一時的な修正を行いました。
npm publish
これで、私が作成した重要なパッチは終わりです。 GENEREADME が使用できるようになりました!
以上がGENEREADME のリリースの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
