貢獻
您可以透過多種不同的方式來貢獻 Nuxt 生態系統。
生態系統
Nuxt 生態系統包含許多不同的專案和組織
- nuxt/ - Nuxt 框架本身的核心儲存庫。nuxt/nuxt 包含 Nuxt 框架（版本 2 和 3）。
- nuxt-modules/ - 社群貢獻和維護的模組和函式庫。有一個遷移模組的流程至
nuxt-modules。雖然這些模組有各自的維護者，但它們不依賴單一個人。 - unjs/ - 這些函式庫中有許多在整個 Nuxt 生態系統中使用。它們被設計為通用函式庫，與框架和環境無關。我們歡迎其他框架和專案的貢獻和使用。
如何貢獻
分類問題並在討論中提供協助
查看您想要協助的專案的問題和討論。例如，以下是 Nuxt 3 的問題看板和討論。協助其他使用者、分享解決方案、建立重現步驟，甚至稍微研究錯誤並分享您的發現，都會帶來巨大的改變。
建立問題
感謝您撥冗建立問題！❤️
- 回報錯誤：查看我們的指南，了解在開啟問題之前可以先做的事情。
- 功能請求：請檢查是否已有現有的問題或討論涵蓋您心中所想的功能範圍。如果該功能是針對 Nuxt 生態系統的另一部分（例如模組），請考慮先在那裡提出功能請求。如果您心中所想的功能是通用的，或者 API 並非完全清楚，請考慮在「想法」區塊開啟討論，先與社群討論。
我們將盡力遵循我們的內部問題決策流程圖，以便在回覆問題時參考。
發送 Pull Request
我們隨時歡迎 Pull Request！❤️
在您開始之前
在您修正錯誤之前，我們建議您檢查是否有問題描述該錯誤，因為有可能是文件問題，或者有一些背景資訊可能對您有所幫助。
如果您正在開發新功能，我們希望您先開啟功能請求問題，與維護者討論是否需要該功能以及這些功能的設計。這有助於為維護者和貢獻者節省時間，並意味著功能可以更快地發布。在 Pull Request 中建構功能之前，問題應先由框架團隊成員確認。
對於錯字修正，建議將多個錯字修正批次處理到一個 Pull Request 中，以保持更乾淨的提交歷史紀錄。
對於 Nuxt 本身的較大變更，我們建議您首先建立 Nuxt 模組並在那裡實作該功能。這允許快速的概念驗證。然後，您可以透過討論的形式建立 RFC。隨著使用者採用它以及您收集回饋，它可以被改進，然後添加到 Nuxt 核心或繼續作為獨立模組。
提交慣例
我們使用 Conventional Commits 作為提交訊息，這允許根據提交自動產生變更日誌。如果您還不熟悉，請完整閱讀指南。
請注意 fix: 和 feat: 用於實際程式碼變更（可能影響邏輯）。對於錯字或文件變更，請改用 docs: 或 chore:
fix: typodocs: 修正錯字
如果您在具有 monorepo 的專案中工作，例如 nuxt/nuxt，請確保在括號中指定提交的主要範圍。例如：feat(nuxi): 新增 'do-magic' 命令。
建立 Pull Request
如果您不知道如何發送 Pull Request，我們建議您閱讀指南。
發送 Pull Request 時，請確保您的 PR 標題也遵循提交慣例。
如果您的 PR 修正或解決了現有的問題，請確保在 PR 描述中提及它們。
在單一 PR 中有多個提交是可以的；您不需要為您的變更執行 rebase 或 force push，因為我們將使用 Squash and Merge 在合併時將提交壓縮為一個提交。
我們沒有新增任何提交鉤子以允許快速提交。但在您建立 Pull Request 之前，您應確保任何 lint/test 腳本都已通過。
一般來說，也請確保 PR 中沒有不相關的變更。例如，如果您的編輯器對您編輯的檔案中其他地方的空白或格式進行了任何變更，請還原這些變更，以便更清楚地了解您的 PR 變更了什麼。並且請避免在單一 PR 中包含多個不相關的功能或修正。如果可以將它們分開，最好有多个 PR 分別進行審查和合併。一般來說，一個 PR 應該只做一件事。
一旦您建立 Pull Request
一旦您建立 Pull Request，我們將盡力及時審查它。
如果我們將其分配給維護者，則表示該人員將特別注意審查它並實作可能需要的任何變更。
如果我們要求在 PR 上進行變更，請忽略紅色文字！這並不表示我們認為這是個不好的 PR - 這只是一種輕鬆查看一系列 Pull Request 狀態的方式。
如果我們將 PR 標記為「待定」，則表示我們可能還有其他任務要完成才能審查 PR - 這是一個內部自我提醒，不一定反映 PR 是否是個好主意。我們將盡力透過註解說明待定狀態的原因。
我們將盡力遵循我們的 PR 決策流程圖，以便在回覆和審查 Pull Request 時參考。
建立模組
如果您使用 Nuxt 建構了一些很棒的東西，何不將其提取到模組中，以便與其他人分享？我們已經有許多很棒的模組，但總是有更多空間。
如果您在建構時需要協助，請隨時與我們聯繫。
提出 RFC
我們強烈建議首先建立模組，以測試大型新功能並獲得社群採用。
如果您已經這樣做了，或者建立新模組不合適，請先建立新的討論。確保它盡可能清楚地解釋您的想法。包含新 API 的程式碼範例或函式簽名。參考現有的問題或痛點並提供範例。
如果我們認為這應該是 RFC，我們會將類別變更為 RFC 並更廣泛地廣播以徵求回饋。
RFC 接著將經歷以下階段
rfc: active- 目前開放評論rfc: approved- 已由 Nuxt 團隊批准rfc: ready to implement- 已建立問題並指派實作rfc: shipped- 已實作rfc: archived- 未批准，但已封存以供未來參考
生態系統中的慣例
以下慣例在 nuxt/ 組織內是必要的，並建議生態系統中的其他維護者使用。
模組慣例
模組應遵循Nuxt 模組範本。請參閱模組指南以取得更多資訊。
使用核心 unjs/ 函式庫
我們建議使用以下在整個生態系統中使用的函式庫
- pathe - 通用路徑工具程式（node
path的替代方案） - ufo - URL 解析和加入工具程式
- unbuild - 由 rollup 驅動的建置系統
- ... 查看 unjs/ 組織的其他部分以取得更多資訊！
使用 ESM 語法並預設為 type: module
大多數 Nuxt 生態系統可以直接使用 ESM。一般來說，我們建議您避免使用 CJS 特定的程式碼，例如 __dirname 和 require 語句。您可以閱讀更多關於 ESM 的資訊。
什麼是 Corepack
Corepack 確保您在執行相應命令時，使用的是正確的套件管理器版本。專案的 package.json 中可能有 packageManager 欄位。
在具有如下所示配置的專案下，Corepack 將安裝 pnpm 的 v7.5.0 版本（如果您尚未安裝），並使用它來執行您的命令。
{
"packageManager": "pnpm@7.5.0"
}
使用 ESLint
我們使用 ESLint 以及 @nuxt/eslint 進行程式碼檢查和格式化。
IDE 設定
我們建議使用 VS Code 以及 ESLint 擴充功能。如果您願意，可以在儲存您正在編輯的程式碼時啟用自動修正和格式化
{
"editor.codeActionsOnSave": {
"source.fixAll": "never",
"source.fixAll.eslint": "explicit"
}
}
無需 Prettier
由於 ESLint 已配置為格式化程式碼，因此無需使用 Prettier 重複此功能。若要格式化程式碼，您可以執行 yarn lint --fix、pnpm lint --fix 或 bun run lint --fix，或參考 ESLint 章節以進行 IDE 設定。
如果您的編輯器中安裝了 Prettier，我們建議您在處理專案時停用它，以避免衝突。
套件管理器
我們建議使用 pnpm 作為模組、函式庫和應用程式的套件管理器。
啟用 Corepack 很重要，以確保您使用的套件管理器版本與專案相同。Corepack 內建於新的 node 版本中，可實現無縫的套件管理器整合。
若要啟用它，請執行
corepack enable
您只需要執行一次，在您的電腦上安裝 Node.js 之後。
文件樣式指南
文件是 Nuxt 不可或缺的一部分。我們的目標是成為一個直覺式的框架 - 而其中很大一部分是確保開發人員體驗和文件在整個生態系統中都臻於完美。👌
以下是一些可能有助於改進文件品質的訣竅
- 盡可能避免使用主觀的詞語，例如「簡單地」、「僅僅」、「顯然...」。
請記住，您的讀者可能有不同的背景和經驗。因此，這些詞語無法傳達意義，並且可能有害。簡單地確保函式返回 Promise。確保函式返回 Promise。 - 偏好主動語態。Nuxt 將會拋出錯誤。Nuxt 將拋出錯誤。