使用 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”資料夾來測試我的程式碼嗎？ 可能不是。您認為我的用戶需要格式化和檢查我的原始程式碼所需的設定檔嗎？ 可能不是。您認為我的用戶是否出於任何特定原因需要使用我的“.github”資料夾？ 可能不是。

為此，我一直在努力尋找一種解決方案來最大程度地減少用戶下載的內容；具體來說，我希望他們只擁有我的程式運行所需的原始碼。

是 .npmignore 還是不 .npmignore？這就是問題所在。

當我考慮重新發布我的程式碼時，我也在和我的朋友 Uday Rana 討論使用 .npmignore 文件來「忽略」我不想發布的文件的想法。

就在我提到這個主題之後，Uday 在Google 上搜尋了.npmignore，並找到了Jeff D 撰寫的一篇關於為什麼人們應該永遠不會使用. npmignore 文件的文章。需要明確的是，我完全同意傑夫的文章。

本質上，這個想法是我們應該明確我們想要發布的內容（白名單），而不是說明我們不 想要發布（列入黑名單）。

使用 npm 將我們想要發布的文件列入白名單非常簡單。我們需要做的就是透過新增「files」選項來編輯 package.json 文件，該選項指示我們要為程式發布哪些文件。

下面，我截取了 package.json 的「files」選項的螢幕截圖，該選項指出「發布此程式時包含 src/ 目錄」。我已經提交了這些更改，並且這些更改可在我的程式碼 v1.0.0 版本中使用。

注意：預設情況下，某些檔案總是發佈到 npm，無論您在「檔案」選項中指定或未指定什麼。如果你想了解更多如何使用「files」選項，請查看 npm 的官方文件如何使用 file 選項。

使用更新後的 package.json 將我的程式碼發佈到 npm 後，安裝/重新安裝 gimme_readme 的用戶現在電腦上的膨脹會少很多！請參閱以下差異：

新增 GitHub 操作以在新增版本時將程式碼發佈到 npm

除了增強用戶體驗（透過減少透過npm 安裝gimme_readme 帶來的臃腫）之外，我還添加了一個持續開發管道（簡稱cd 管道），當我創建新的專案時，它可以將我的發布流程自動化到npm在GitHub 上發布。有關如何執行此操作的具體詳細信息，您可以參閱 GitHub 的發布 Node.js 包指南。現在感覺很好，因為只需點擊幾個按鈕，我就可以發布我知道穩定的程式碼（根據我的 CI 管道），來自 GitHub。

您可以在這裡找到我的 cd 管道的程式碼。

與烏代一起測試

正如我之前提到的，我正在與我的朋友 Uday Rana 一起進行測試。在撰寫本文時，他能夠安裝我的工具，並像這樣使用它：

事情對我來說看起來不錯，而且我的工具的大多數選項或多或少都符合他的預期。但我必須再次重複這個過程，因為我想添加一些進一步的優化！

旅程永無止境……但這就是它的樂趣所在！

我最近也聽說了進一步優化我的程式碼的方法。特別是，我致力於學習如何透過了解複合操作以及與 GitHub 操作相關的可重複使用工作流程來改善我的 CI 和 CD 管道。我希望這些技術能幫助我減少編寫的程式碼量，並提供某種類型的效能提升！我對這些主題還不太了解，但你可以打賭我可能很快就會在部落格上介紹它。

我的朋友們，結束了我想在這個部落格中談論的內容。

下次見！

以上是使用 GitHub Actions 將 gimme_readme 重新發佈到 npm的詳細內容。更多資訊請關注PHP中文網其他相關文章！