貢献

プロジェクト構造、開発ワークフロー、ベストプラクティスを含む、Nuxt UIへの貢献に関する包括的なガイド。

Nuxt UIは素晴らしいコミュニティのおかげで繁栄します❤️.このライブラリをより良くするために、バグレポート、プルリクエスト、フィードバックを通じたすべての貢献を歓迎します。

バグを報告したり、機能をリクエストしたりする前に、 documentation と既存の issues を読んでください。質問やヘルプについては、 GitHub Discussions をご利用ください。

AIアシスト

Nuxt UIへの貢献を支援するために、AIアシスタント向けにAGENTS.mdを通じて貢献ガイドラインを提供しています。このガイドラインは、すべてのAIコーディングエージェントによって自動的にピックアップされ、コンポーネント構造、テーマパターン、テスト規約、ドキュメントガイドラインを通じてガイドされます。

プロジェクト構造

Nuxt UIプロジェクト構造内の主要なディレクトリとファイルの概要は次のとおりです。

ドキュメント

ドキュメントはdocsフォルダにあり、@nuxt/contentを使用してMarkdownファイルからページを生成するNuxtアプリです。どのように動作するかの詳細は Nuxt Content documentation を参照してください。構造の内訳は次のとおりです。

├── app/
│   ├── assets/
│   ├── components/
│   │   └── content/
│   │       └── examples   # Components used in documentation as examples
│   ├── composables/
│   └── ...
├── content/
│   ├── blog/
│   ├── docs/
│   │   ├── 1.getting-started
│   │   ├── 2.components   # Components documentation
│   │   ├── 3.composables
│   │   └── 4.typography
│   └── ...            # Landing pages (index.yml, showcase.yml...)

モジュール

モジュールコードはsrcフォルダにあります。以下はその構造の内訳です。

├── plugins/
├── runtime/
│   ├── components/        # Where all the components are located
│   │   ├── Accordion.vue
│   │   ├── Alert.vue
│   │   └── ...
│   ├── composables/
│   ├── locale/
│   ├── plugins/
│   ├── types/
│   ├── utils/
│   └── vue/
│       ├── components/
│       └── plugins/
├── theme/                 # This where the theme for each component is located
│   ├── accordion.ts       # Theme for Accordion component
│   ├── alert.ts
│   └── ...
├── utils/
└── module.ts

CLI

開発を容易にするために、コンポーネントとロケールの生成に使用できるCLIを作成しました。pnpm cli makeコマンドを使用してアクセスできます。

コンポーネント

次のコマンドを使用して新しいコンポーネントを作成できます。

pnpm cli make component <name> [options]

利用可能なオプション

  • --primitiveプリミティブコンポーネントを作成
  • --prose散文コンポーネントを作成する
  • --contentコンテンツコンポーネントを作成します。
  • --template特定のテンプレートのみを生成します(利用可能なテンプレート:playground、docs、test、theme、component)

例

# Create a basic component
pnpm cli make component my-component

# Create a prose component
pnpm cli make component heading --prose

# Create a content component
pnpm cli make component block --content

# Generate only documentation template
pnpm cli make component my-component --template=docs
新しいコンポーネントを作成すると、CLIはコンポーネント自体、テーマ、テスト、ドキュメントなどの必要なすべてのファイルを自動的に生成します。

Locales

次のコマンドを使用して新しいロケールを作成できます。

pnpm cli make locale --code <code>

ロケール名と方向は CLDR から入力され、コードはそれに対して検証されます。--nameと--dirフラグで上書きできます。

メッセージを翻訳したら、次のように実行してロケールが他のロケール(メッセージキー、プレースホルダー、名前、方向)と一貫していることを確認できます。

pnpm test locale --run
** i18n **について詳しくは、ドキュメントを参照してください。

プルリクエスト(PR)を送信

作業を始める前に、作業中の問題または機能リクエストを説明する既存の問題がないか確認してください。存在する場合は、問題についてコメントを残して、作業中であることをお知らせください。

ない場合は、新しい問題を開いて問題や機能について議論してください。

地域開発

地域開発を始めるには、以下の手順に従う。

nuxt/uiリポジトリをローカルマシンにクローンします。

git clone -b v4 https://github.com/nuxt/ui.git

有効化 Corepack

corepack enable

インストール依存関係

pnpm install

型スタブを生成する

pnpm run dev:prepare

開発開始

  • docsフォルダにある** documentation **を操作するには、次のように実行します。
pnpm run docs
  • ** playground **を使用してNuxtコンポーネントをテストするには、次のように実行します。
pnpm run dev
  • ** playground **を使用してVueコンポーネントをテストするには、次のように実行します。
pnpm run dev:vue
新しいコンポーネントの実装に取り組んでいる場合は、** CLI **セクションをチェックして、プロセスを開始してください。

IDEセットアップ

ESLint extension と一緒にVSCodeを使用することをお勧めします。コードを保存するときに自動修正とフォーマットを有効にすることができます。方法は次のとおりです。

.vscode/settings.json
{
  "editor.codeActionsOnSave": {
    "source.fixAll": "never",
    "source.fixAll.eslint": "explicit"
  },
  "prettier.enable": false
}
ESLintは既にコードをフォーマットするように設定されていますので、** Prettier **で機能を複製する必要はありません。エディタにインストールされている場合は、競合を避けるために無効にすることをお勧めします。

リンティング

lintコマンドを使用して、リンティングエラーを確認できます。

pnpm run lint # check for linting errors
pnpm run lint:fix # fix linting errors

型チェック

型チェックにはTypeScriptを使用します。typecheckコマンドを使用して型エラーをチェックできます。

pnpm run typecheck

テスト

PRを送信する前に、テストを実行してください。

pnpm run test
スナップショットを更新する必要がある場合は、テストの実行が終了した後にuを押してください。

コミット規約

コミットメッセージには Conventional Commits を使用しています。これにより、コミットに基づいて変更履歴を自動生成できます。まだ慣れていない方は、 guide をお読みください。

  • fixおよびfeatを使用して、機能やロジックに影響を与えるコード変更
  • ドキュメントの変更にはdocsを、メンテナンスタスクにはchoreを使用します。

プルリクエストの作成

  • PR作成時に提供される instructions に従ってください
  • PRのタイトルが Conventional Commits に準拠していることを確認してください。
  • 複数のコミットは問題ありません。リベースや強制プッシュは必要ありません。マージ時にはSquash and Mergeを使用します。
  • lint、typecheck、testsはPRを送信する前に動作します。無関係な変更は避けてください。

私たちは速やかにレビューします。メンテナに割り当てられた場合、彼らは慎重にレビューします。赤いテキストは無視してください。これは追跡目的です。

ありがとう

このプロジェクトに興味を持っていただきありがとうございます!あなたは素晴らしいです!❤️