貢獻

您可以用許多不同的方式為 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: typo -> docs: fix typo

如果您正在使用單一儲存庫的專案（如 nuxt/nuxt），請確保在括號中指定提交的主要範圍。例如：feat(nuxi): add 'do-magic' command。

建立 Pull Request

如果您不知道如何發送 pull request，我們建議您閱讀 指南。

發送 pull request 時，請確保您的 PR 標題也遵循 提交慣例。

如果您的 PR 修正或解決了現有的問題，請確保您在 PR 描述中提及它們。

在單個 PR 中有多個提交是可以的；您不需要針對您的變更進行 rebase 或 force push，因為我們將在合併時使用 Squash and Merge 將提交合併為一個提交。

我們不會新增任何提交鉤子以允許快速提交。但在您發出 pull request 之前，您應該確保任何 lint/測試腳本都通過了。

一般來說，請確保 PR 中沒有不相關的變更。舉例來說，如果您的編輯器在您編輯的檔案中，對其他地方的空白或格式進行了任何變更，請還原這些變更，以便更清楚地顯示您的 PR 變更了哪些內容。並且請避免在單一 PR 中包含多個不相關的功能或修復。如果可以將它們分開，最好有多个 PR 分別進行審閱和合併。一般來說，一個 PR 應該只做一件事。

提交 Pull Request 之後

一旦您提交了 pull request，我們會盡力盡快審閱。

如果我們將其指派給維護者，則表示該人員將特別注意審閱並實施可能需要的任何變更。

如果我們在 PR 上要求變更，請忽略紅色文字！這並不表示我們認為這是個不好的 PR，這只是一種方便一目瞭然地判斷 pull request 清單狀態的方式。

如果我們將 PR 標記為「pending（待處理）」，則表示我們可能在審閱 PR 時還有其他任務要做，這是一個內部的自我提醒，不一定反映 PR 的好壞。我們會盡力透過評論解釋待處理狀態的原因。

我們在回應和審閱 pull request 時，會盡力遵循我們的 PR 決策流程圖。

建立模組

如果您使用 Nuxt 建立了一些很酷的東西，何不將其提取到模組中，以便與其他人分享？我們已經有許多很棒的模組，但總是有空間容納更多。

如果您在建立時需要幫助，請隨時與我們聯繫。

提出 RFC

我們強烈建議您先建立模組，以測試大型新功能並獲得社群的採用。

如果您已經這樣做了，或者不適合建立新模組，那麼請先建立一個新的討論。確保盡可能清楚地解釋您的想法。包含新 API 的程式碼範例或函式簽名。參考現有的問題或痛點，並附上範例。

如果我們認為這應該是 RFC，我們會將類別變更為 RFC，並更廣泛地廣播以徵求意見回饋。

RFC 接下來將經歷以下階段

• rfc: active - 目前開放評論
• rfc: approved - 已由 Nuxt 團隊批准
• rfc: ready to implement - 已建立並指派實作的 issue
• 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 會拋出錯誤。