コントリビューション・Nuxtコミュニティ

Nuxtエコシステムに貢献できる方法はさまざまです。

エコシステム

Nuxtエコシステムには、多くの異なるプロジェクトと組織が含まれています。

nuxt/ - Nuxtフレームワーク自体の主要リポジトリです。nuxt/nuxtには、Nuxtフレームワーク（バージョン2と3の両方）が含まれています。
nuxt-modules/ - コミュニティが貢献し、維持管理しているモジュールとライブラリです。モジュールの移行プロセスがnuxt-modulesに存在します。これらのモジュールは個々のメンテナが担当していますが、単一の人物に依存していません。
unjs/ - これらのライブラリの多くは、Nuxtエコシステム全体で使用されています。フレームワークと環境に依存しないユニバーサルライブラリとして設計されています。他のフレームワークやプロジェクトによるコントリビューションと使用を歓迎します。

コントリビューションの方法

問題のトリアージとディスカッションへの参加

手伝いたいプロジェクトの問題とディスカッションを確認してください。たとえば、Nuxt 3の問題ボードとディスカッションがあります。他のユーザーの支援、回避策の共有、再現の作成、あるいはバグを少し掘り下げて調査結果を共有するだけでも、大きな違いを生みます。

問題の作成

問題作成にご協力いただきありがとうございます！ ❤️

バグの報告：問題を開く前に実行するいくつかの手順については、ガイドをご覧ください。
機能リクエスト：既存の問題や、考えている機能の範囲を網羅したディスカッションがないか確認してください。機能がNuxtエコシステムの他の部分（モジュールなど）にある場合は、まずそこで機能リクエストを検討してください。考えている機能が一般的であるか、APIが完全に明確でない場合は、まずコミュニティと話し合うために、アイデアセクションでディスカッションを開くことを検討してください。

問題への対応には、内部の問題解決フローチャートに従います。

プルリクエストの送信

プルリクエストを常に歓迎しています！ ❤️

開始前に

バグを修正する前に、それを説明する問題が存在するかどうかを確認することをお勧めします。ドキュメントの問題である可能性、または知っておくと役立つコンテキストが存在する可能性があります。

機能に取り組んでいる場合は、まず機能リクエストの問題を開いて、メンテナと機能の必要性と設計について話し合うようにしてください。これにより、メンテナとコントリビュータの両方の時間を節約し、機能をより迅速に提供できます。プルリクエストで機能を作成する前に、問題はフレームワークチームメンバーによって確認される必要があります。

タイプミス修正の場合は、よりクリーンなコミット履歴を維持するために、複数のタイプミス修正を1つのプルリクエストにまとめて行うことをお勧めします。

Nuxt自体へのより大きな変更については、まずNuxtモジュールを作成してそこで機能を実装することをお勧めします。これにより、迅速な概念実証が可能になります。その後、ディスカッション形式でRFCを作成できます。ユーザーが採用し、フィードバックを集めるにつれて、Nuxtコアに追加するか、スタンドアロンモジュールとして継続するかを検討できます。

コミット規約

コミットメッセージにはConventional Commitsを使用します。これにより、コミットに基づいて変更ログを自動生成できます。まだ慣れていない場合は、ガイドをよく読んでください。

fix:とfeat:は実際のコード変更（ロジックに影響を与える可能性のある変更）用です。タイプミスやドキュメントの変更には、代わりにdocs:またはchore:を使用してください。

~~fix: typo~~ -> docs: fix typo

nuxt/nuxtなどのモノレポで作業している場合は、角括弧でコミットの主要なスコープを指定してください。例：feat(nuxi): add 'do-magic' command。

プルリクエストの作成

プルリクエストの送信方法がわからない場合は、ガイドを読むことをお勧めします。

プルリクエストを送信する際には、PRのタイトルもコミット規約に従ってください。

PRが既存の問題を修正または解決する場合は、PRの説明でそれらに必ず言及してください。

1つのPRに複数のコミットを含めることは問題ありません。変更をリベースしたり、強制的にプッシュする必要はありません。マージ時にコミットを1つのコミットにまとめるためにSquash and Mergeを使用します。

迅速なコミットを可能にするために、コミットフックを追加していません。しかし、プルリクエストを作成する前に、すべてのlint/テストスクリプトがパスしていることを確認する必要があります。

一般的に、PRには無関係な変更を含めないでください。たとえば、編集者が編集したファイルの他の場所で空白やフォーマットを変更した場合、それらを元に戻して、PRの変更内容をより明確にする必要があります。また、複数の無関係な機能や修正を1つのPRに含めることは避けてください。分離できる場合は、複数のPRを作成して個別にレビューおよびマージすることをお勧めします。一般的に、PRは1つのことだけを行う必要があります。

プルリクエストの作成後

プルリクエストを作成したら、迅速にレビューいたします。

メンテナに割り当てられた場合は、その人が特に注意してレビューし、必要な変更を実装します。

PRに変更を要求した場合、赤いテキストは無視してください！悪いPRだと思うという意味ではありません。単にプルリクエストのリストのステータスを簡単に確認する方法です。

PRを「保留中」としてマークした場合は、PRのレビューで実行する必要がある別のタスクがある可能性があります。これは内部メモであり、PRが良いアイデアかどうかを反映しているわけではありません。保留中のステータスの理由については、コメントで説明いたします。

プルリクエストへの対応とレビューには、PRの意思決定フローチャートに従います。

モジュールの作成

Nuxtを使って素晴らしいものを作成したなら、なぜそれをモジュールに抽出して、他の人と共有しないのですか？すでに多くの優れたモジュールがありますが、常にさらに多くのモジュールが必要です。

作成中にヘルプが必要な場合は、お気軽にお問い合わせください。

RFCの作成

大きな新しい機能を試してコミュニティの採用を得るには、まずモジュールを作成することを強くお勧めします。

既に作成済みの場合、または新しいモジュールを作成するのが適切でない場合は、新しいディスカッションを作成することから始めてください。考え方をできるだけ明確に説明してください。新しいAPIのコード例または関数シグネチャを含めてください。既存の問題や問題点を例を挙げて参照してください。

これがRFCであると思われる場合は、カテゴリをRFCに変更し、フィードバックのためにより広く公開します。

RFCは、次の段階を経て進みます。

rfc: active - 現在コメント受付中
rfc: approved - Nuxtチームによって承認済み
rfc: ready to implement - 実装するために問題が作成され、割り当てられています
rfc: shipped - 実装済み
rfc: archived - 承認されませんでしたが、将来の参照のためにアーカイブされています

エコシステム全体での規約

nuxt/組織内では次の規約が必須であり、エコシステム内の他のメンテナにも推奨されます。

モジュールの規約

モジュールはNuxtモジュールテンプレートに従う必要があります。モジュールガイドで詳細情報をご覧ください。

コア`unjs/`ライブラリの使用

エコシステム全体で使用されている次のライブラリをお勧めします。

pathe - ユニバーサルパスユーティリティ（ノードpathの代替）
ufo - URLの解析と結合ユーティリティ
unbuild - rollupベースのビルドシステム
…unjs/組織の残りの部分も参照してください！

ESM構文の使用と`type: module`へのデフォルト設定

Nuxtエコシステムの大部分は、ESMを直接使用できます。__dirnameやrequireステートメントなど、CJS固有のコードの使用は避けることをお勧めします。ESMの詳細を読むことができます。

Corepackとは

Corepackは、対応するコマンドを実行するときに、正しいバージョンのパッケージマネージャーを使用していることを確認します。プロジェクトには、package.jsonにpackageManagerフィールドが含まれている場合があります。

以下に示す構成を持つプロジェクトでは、Corepackはpnpmのv7.5.0を（まだインストールされていない場合）インストールし、それを使用してコマンドを実行します。

package.json

{
  "packageManager": "pnpm@7.5.0"
}

ESLintの使用

ESLintを、@nuxt/eslint-configを使用したlintとフォーマットの両方に使用します。

IDEの設定

Visual Studio Code (VS Code) と ESLint 拡張機能 (ESLint extension) の使用を推奨します。必要に応じて、編集中のコードを保存時に自動修正とフォーマットを有効にすることができます。

settings.json

{
  "editor.codeActionsOnSave": {
    "source.fixAll": "never",
    "source.fixAll.eslint": "explicit"
  }
}

Prettier は不要です

ESLint は既にコードのフォーマット用に設定されているため、Prettier で機能を重複させる必要はありません。コードをフォーマットするには、yarn lint --fix、pnpm lint --fix、またはbun run lint --fix を実行するか、IDE 設定については ESLint セクションを参照してください。

エディターに Prettier がインストールされている場合は、競合を避けるためにプロジェクト作業中は無効にすることをお勧めします。

注記：将来的に Prettier を有効にすることを検討しています。

パッケージマネージャー

ライブラリには pnpm を推奨します。モジュールについては、引き続き yarn を推奨しますが、Nuxt 自体でプラグアンドプレイモードをサポートするようになったら、この推奨事項を pnpm に変更する可能性があります。

プロジェクトと同じバージョンのパッケージマネージャーを使用するには、Corepack を有効にすることが重要です。 Corepack は新しい Node.js バージョンに組み込まれており、パッケージマネージャーとのシームレスな統合を実現します。

有効にするには、以下を実行します。

ターミナル

corepack enable

これは、コンピューターに Node.js をインストールした後、一度だけ実行する必要があります。

ドキュメントスタイルガイド

ドキュメントは Nuxt の重要な部分です。直感的なフレームワークを目指しており、その大きな部分は、開発者エクスペリエンスとドキュメントの両方がエコシステム全体で完璧であることを確認することです。 👌

ドキュメントの改善に役立つヒントをいくつかご紹介します。

可能な限り、「簡単に」、「ただ」、「明らかに…」などの主観的な言葉は避けてください。
読者にはさまざまな背景と経験があることを念頭に置いてください。したがって、これらの言葉は意味を伝えず、有害になる可能性があります。
関数が Promise を返すようにするだけです。
関数が Promise を返すようにしてください。
能動態を優先してください。
Nuxt によってエラーがスローされます。
Nuxt がエラーをスローします。

ドキュメントへの貢献方法を学びましょう。

バグの報告

オープンソースにおける最も貴重な役割の1つは、バグを役立つ方法で報告することに時間をかけることです。

フレームワーク

フレームワークリポジトリへの貢献に関する具体的な点について説明します。