貢献

Nuxt はコミュニティプロジェクトです。そのため、あらゆる種類のコントリビューションを歓迎します! ❤️

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

エコシステム

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

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

貢献方法

問題のトリアージとディスカッションでの支援

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

課題の作成

課題を作成するために時間を割いていただきありがとうございます! ❤️

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

課題に対応する際は、内部の課題決定フローチャートに従って最善を尽くします。

プルリクエストの送信

プルリクエストはいつでも歓迎します! ❤️

開始する前に

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

機能を開発している場合は、その機能が必要かどうか、およびその機能の設計についてメンテナと話し合うために、まず機能リクエストの課題を開くようお願いします。これにより、メンテナと貢献者の両方の時間を節約でき、機能がより迅速に出荷されます。プルリクエストで機能を構築する前に、フレームワークチームのメンバーによって課題が確認される必要があります。

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

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

コミット規約

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

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

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

nuxt/nuxtのようなモノレポを持つプロジェクトで作業している場合は、コミットの主要なスコープを角括弧で指定してください。例: feat(kit): add 'addMagicStuff' utility。

プルリクエストの作成

プルリクエストの送信方法がわからない場合は、ガイド.

を読むことをお勧めします。プルリクエストを送信する際は、PRのタイトルがコミット規約に従っていることを確認してください。

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

単一のPRに複数のコミットがあっても構いません。Squash and Mergeを使用してコミットを1つにスカッシュしてマージするため、変更のためにリベースや強制プッシュする必要はありません。

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

一般的に、PRに無関係な変更がないことを確認してください。たとえば、エディターが編集したファイルの別の場所で空白や書式設定を変更した場合、それらを元に戻して、PRの変更内容がより明確になるようにしてください。また、単一のPRに複数の無関係な機能や修正を含めることは避けてください。分離できる場合は、複数のPRを作成して個別にレビューおよびマージする方が良いでしょう。一般的に、PRは1つのことだけを行うべきです。

プルリクエストを作成したら

プルリクエストを作成したら、迅速にレビューできるよう最善を尽くします。

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

PRに変更を要求した場合、赤いテキストを無視してください！それはPRが悪いという意味ではなく、プルリクエストのリストのステータスを一目で簡単に伝えるための方法です。

PRを「保留中」とマークした場合、それはPRのレビューにおいて別のタスクがあることを意味します。これは内部的なメモであり、PRが良いアイデアであるかどうかを必ずしも反映するものではありません。保留中の理由については、コメントで説明するよう最善を尽くします。

プルリクエストへの対応とレビューの際には、当社のPR意思決定フローチャートに従うよう最善を尽くします。

AIアシストによる貢献

Nuxtへの貢献においてAIツールの思慮深い使用を歓迎しますが、すべての貢献者に2つの主要な原則.

LLMにあなたに代わって話させてはならない

すべてのコメント、課題、プルリクエストの説明は、あなた自身の言葉で書かれるべきです。
完璧な文法やスペルよりも、明確な人間によるコミュニケーションを重視します。
あなた自身の理解を反映しない、AIが生成した要約のコピー＆ペーストは避けてください。

LLMにあなたに代わって考えさせてはならない

コードを生成したり、アイデアを探求したりするためにAIツールを自由に利用してください。
あなたが完全に理解し、説明できる貢献のみを提出してください。
貢献はあなた自身の推論と問題解決を反映しているべきです。

私たちの目標は、品質を確保し、現実の人々とのコラボレーションとコミュニケーションの喜びを維持することです。NuxtコミュニティにおけるAIに関するポリシーを改善するためのアイデアがあれば、ぜひお聞かせください！❤️

モジュールの作成

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を直接消費できます。一般的に、__dirnameやrequire文など、CJS固有のコードの使用は避けることを推奨しています。ESMの詳細はこちらで確認できます。

Corepackとは

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

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

package.json

{
  "packageManager": "[email protected]"
}

リンティングとフォーマットの両方に

コミットメッセージにはESLintESLintの使用@nuxt/eslint.

IDEセットアップ

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

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がインストールされている場合は、競合を避けるため、プロジェクト作業中は無効にすることをお勧めします。

パッケージマネージャー

モジュール、ライブラリ、およびアプリのパッケージマネージャーとしてpnpmをお勧めします。

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

有効にするには、実行してください

ターミナル

corepack enable

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

ドキュメンテーションスタイルガイド

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

ドキュメントを改善するのに役立ついくつかのヒントを以下に示します。

可能な限り、簡単に、ただ、明らかに...といった主観的な言葉は避けてください。
読者には異なる背景や経験がある可能性があることに留意してください。したがって、これらの言葉は意味を伝えられず、有害となる可能性があります。
関数がプロミスを返すことを簡単に確認してください。
関数がプロミス.
を返すことを確認してください。能動態.
を推奨します。Nuxtによってエラーがスローされます。
Nuxtがエラーをスローします。

ドキュメントに貢献する方法を学びましょう。

お役に立ちましたか？

問題を報告またはGitHub でこのページを編集

バグの報告

オープンソースで最も価値のある役割の1つは、バグを役立つ形で報告する時間を費やすことです。

フレームワーク

フレームワークリポジトリへの貢献に関するいくつかの具体的なポイント。