GitHub Actions を使用して gimme_readme を npm に再公開する

今週のオープン ソース クラスでは、クラスメートと私は、独自のプログラムをそれぞれパッケージ レジストリに公開するという課題を課されました。

誰かがコード レジストリ、パッケージ レジストリ、またはレジストリと言うのを聞くと、これらの言葉は開発者や企業が他の人がダウンロードできるようにコードを公開する場所を表すものだと考えたいと思います。より正確な説明については、Mozilla の次の記事を参照してください。

パッケージ管理の基本 - Web 開発を学ぶ | MDN

これで、パッケージ マネージャーのツアーは終了です。私たちの次の行動は、これまで学んだことをすべて実践して、サンプル ツールチェーンを構築することです。

gimme_readme - npm

gimme_readme は、AI を活用したコマンドライン ツールで、プロジェクトの包括的な README.md ファイルを生成します。複数のソース コード ファイルを一度に分析し、各ファイルの目的、機能、主要コンポーネントの簡潔な説明を提供します。最新バージョン: 1.0.0、最終公開日: 16 時間前。 `npm i gimme_readme` を実行して、プロジェクトで gimme_readme の使用を開始します。 npm レジストリには、gimme_readme を使用する他のプロジェクトはありません。

上でわかるように、(開発者とは対照的に) ユーザー にとって不要なフォルダーやファイルがたくさんあります。たとえば、ユーザーは私の「tests」フォルダーで私のプログラムのコードをテストすることを望むと思いますか? おそらくそうではありません。私のソース コードをフォーマットして lint するために必要な設定ファイルがユーザーに必要だと思いますか? おそらくそうではありません。私のユーザーは何らかの特別な理由で私の「.github」フォルダーを使用する必要があると思いますか? おそらくそうではありません。

この目的のために、私はユーザーがダウンロードするものを最小限に抑える解決策を見つけるために取り組んできました。具体的には、プログラムの実行に必要なソース コードのみを提供してもらいたいと考えています。

.npmignore するかしないか?それが質問です。

コードを再公開することを考えていたとき、友人の Uday Rana とも、公開したくないファイルを .npmignore ファイルを使用して「無視」するというアイデアについて話していました。

私がこのトピックについて言及した直後、Uday は .npmignore を Google で検索し、.npmignore ファイルを決して使用してはいけない理由について Jeff D が書いた記事を見つけました。はっきり言っておきますが、私は Jeff の記事に全面的に同意します。

基本的に、どのファイルを公開しないかを明示するのではなく、公開したい内容(ホワイトリスト登録)を明示的すべきであるという考え方です。 > 公開したい (ブラックリストに登録)。

npm を使用すると、公開したいファイルをホワイトリストに登録するのが簡単です。必要なのは、プログラム用にどのファイルを公開するかを示す「file」オプションを追加して package.json ファイルを編集することだけです。

以下は、package.json の「files」オプションのスクリーンショットです。「このプログラムを公開するときに src/ ディレクトリを含める」と記載されています。その後、これらの変更をコミットし、コードの v1.0.0 リリースで利用できるようになりました。

注: デフォルトでは、「files」オプションで何を指定したか指定しなかったかに関係なく、特定のファイルは常に npm に公開されます。 「files」オプションの使用方法について詳しく知りたい場合は、npm の公式ドキュメントで file オプションの使用方法を確認してください。

更新された package.json を使用してコードを npm に公開した後、gimme_readme をインストール/再インストールするユーザーのコンピューターの肥大化が大幅に軽減されます。以下の違いをご覧ください:

新しいリリースを追加するときにコードを npm に公開する GitHub アクションを追加する

(npm 経由で gimme_readme をインストールすることによる肥大化を軽減することで) ユーザーのエクスペリエンスを向上させることに加えて、新しいファイルを作成するときに npm への公開プロセスを自動化する継続的開発パイプライン (略して cd パイプライン) も追加しました。 GitHub でリリースします。これを行う方法の正確な詳細については、GitHub の Node.js パッケージの公開ガイドを参照してください。ボタンを数回クリックするだけで、(CI パイプラインに従って) 安定しているとわかっているコードを GitHub から から 公開できるので、これで良い感じです。

私の CD パイプラインのコードはここにあります。

ウダイを使ったテスト

前に述べたように、私はテストに関して友人の Uday Rana と協力していました。この記事を書いている時点では、彼は私のツールをインストールして次のように使用することができました。

私にとって物事はうまくいっているようで、私のツールに用意されているオプションのほとんどは、多かれ少なかれ彼の期待どおりに動作します。ただし、さらに最適化を追加したいため、このプロセスをもう一度繰り返す必要があります!

旅に終わりはありません…でも、だからこそ楽しいのです！

最近、コードをさらに最適化する方法についても聞きました。特に、GitHub アクションに関する複合アクションや再利用可能なワークフローについて学習することで、CI および CD パイプラインを改善する方法を学ぶことに熱心に取り組んでいます。これらのテクニックによって、作成するコードの量が減り、何らかのパフォーマンスが向上することを願っています。これらのトピックについてはまだあまり知りませんが、おそらく近いうちにブログに書くことになると思います。

そして、私の友人たち、これで私がこのブログで話したかったことは終わります。

また次回お会いしましょう!

以上がGitHub Actions を使用して gimme_readme を npm に再公開するの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。