Nuxtの設定とフックシステムを使用すると、Nuxtのあらゆる側面をカスタマイズし、必要な統合（Vueプラグイン、CMS、サーバールート、コンポーネント、ログ記録など）を追加することが可能です。

Nuxtモジュールは、nuxt devを使用して開発モードでNuxtを開始する際や、nuxt buildでプロジェクトを本番用にビルドする際に順次実行される関数です。モジュールを使用すると、プロジェクトに不要なボイラープレートを追加したり、Nuxt自体に変更を加えることなく、カスタムソリューションをnpmパッケージとしてカプセル化し、適切にテストし、共有することができます。

クイックスタート

Nuxtモジュールを始めるには、スターターテンプレートを使用することをお勧めします：

npm create nuxt -- -t module my-module

これにより、モジュールを開発および公開するために必要なすべてのボイラープレートを備えたmy-moduleプロジェクトが作成されます。

次のステップ:

1. お好みのIDEでmy-moduleを開く
2. お気に入りのパッケージマネージャーを使用して依存関係をインストールする
3. npm run dev:prepareを使用して開発用のローカルファイルを準備する
4. このドキュメントを参照してNuxtモジュールについてさらに学ぶ

スターターの使用

モジュールスターターを使用して基本的なタスクを実行する方法を学びます。

開発方法

モジュールのソースコードは通常srcディレクトリ内にありますが、モジュールを開発するにはNuxtアプリケーションが必要です。それがplaygroundディレクトリの目的です。これは、すでにモジュールと一緒に実行するように設定されたNuxtアプリケーションです。

playgroundを通常のNuxtアプリケーションのように操作できます。

• npm run devで開発サーバーを起動し、srcディレクトリでモジュールに変更を加えると自動的にリロードされます
• npm run dev:buildでビルドします

テスト方法

モジュールスターターには基本的なテストスイートが付属しています：

• ESLintによるリンター、npm run lintで実行します
• Vitestによるテストランナー、npm run testまたはnpm run test:watchで実行します

ビルド方法

Nuxtモジュールには、@nuxt/module-builderによって提供される独自のビルダーが付属しています。このビルダーは、あなたの側での設定を必要とせず、TypeScriptをサポートし、他のNuxtアプリケーションに配布するためにアセットが適切にバンドルされることを保証します。

npm run prepackを実行してモジュールをビルドできます。

公開方法

モジュールのバージョンを上げてnpm publishコマンドを使用してモジュールを公開することもできますが、モジュールスターターには、モジュールの動作するバージョンをnpmに公開することを確認するためのリリーススクリプトが付属しています。

リリーススクリプトを使用するには、まずすべての変更をコミットします（自動バージョンアップと変更ログの更新を利用するためにConventional Commitsに従うことをお勧めします）、次にnpm run releaseでリリーススクリプトを実行します。

リリーススクリプトを実行すると、次のことが行われます：

• まず、テストスイートを実行します：
  • リンターを実行します（npm run lint）
  • 単体テスト、統合テスト、e2eテストを実行します（npm run test）
  • モジュールをビルドします（npm run prepack）
• 次に、テストスイートが正常に終了した場合、次の手順でモジュールを公開します：
  • モジュールのバージョンを上げ、Conventional Commitsに基づいて変更ログを生成します
  • モジュールをnpmに公開します（この目的のために、モジュールは再度ビルドされ、公開されたアーティファクトに更新されたバージョン番号が考慮されることを保証します）
  • 新しく公開されたバージョンを表すgitタグをgitリモートオリジンにプッシュします

モジュールの開発

Nuxtモジュールは、Nuxtアプリケーションをあらゆる方法で変更するための強力なAPIとパターンを備えています。このセクションでは、それらを活用する方法を学びます。

モジュールの構造

Nuxtモジュールには2種類あります：

• 公開されたモジュールはnpmで配布されます - Nuxtウェブサイトでいくつかのコミュニティモジュールのリストを見ることができます。
• "ローカル"モジュールは、Nuxtプロジェクト内に存在し、Nuxt設定にインライン化されているか、modulesディレクトリの一部として存在します。

いずれの場合も、その構造は似ています。

モジュール定義

モジュール定義は、モジュールのエントリーポイントです。これは、Nuxt設定内でモジュールが参照されたときにNuxtによってロードされるものです。

低レベルでは、Nuxtモジュール定義は、インラインユーザーオプションとNuxtと対話するためのnuxtオブジェクトを受け入れる、単純で非同期の可能性がある関数です。

export default function (inlineOptions, nuxt) {
  // ここで好きなことを行うことができます...
  console.log(inlineOptions.token) // `123`
  console.log(nuxt.options.dev) // `true`または`false`
  nuxt.hook('ready', async nuxt => {
    console.log('Nuxt is ready')
  })
}

この関数に対する型ヒントのサポートを得るには、Nuxt Kitによって提供される高レベルのdefineNuxtModuleヘルパーを使用します。

import { defineNuxtModule } from '@nuxt/kit'

export default defineNuxtModule((options, nuxt) => {
  nuxt.hook('pages:extend', pages => {
    console.log(`Discovered ${pages.length} pages`)
  })
})

ただし、この低レベルの関数定義を使用することはお勧めしません。代わりに、モジュールを定義するには、特にnpmに公開する場合、モジュールを識別するためのmetaプロパティを持つオブジェクト構文を使用することをお勧めします。

このヘルパーは、モジュールに必要な多くの一般的なパターンを実装し、将来の互換性を保証し、モジュール作成者とユーザーの両方にとっての体験を向上させることで、Nuxtモジュールの記述をより簡単にします。

import { defineNuxtModule } from '@nuxt/kit'

export default defineNuxtModule({
  meta: {
    // 通常はモジュールのnpmパッケージ名
    name: '@nuxtjs/example',
    // `nuxt.config`内でモジュールオプションを保持するキー
    configKey: 'sample',
    // 互換性の制約
    compatibility: {
      // サポートされているnuxtバージョンのSemverバージョン
      nuxt: '>=3.0.0'
    }
  },
  // モジュールのデフォルト設定オプション、これらを返す関数であることも可能
  defaults: {},
  // Nuxtフックを登録するためのショートハンドシュガー
  hooks: {},
  // モジュールロジックを保持する関数、非同期であることも可能
  setup(moduleOptions, nuxt) {
    // ...
  }
})

最終的にdefineNuxtModuleは、低レベルの(inlineOptions, nuxt)モジュールシグネチャを持つラッパー関数を返します。このラッパー関数は、setup関数を呼び出す前にデフォルトやその他の必要なステップを適用します：

• モジュールオプションを自動的にマージするためのdefaultsとmeta.configKeyのサポート
• 型ヒントと自動型推論
• 基本的なNuxt 2互換性のためのシムを追加
• meta.nameまたはmeta.configKeyから計算された一意のキーを使用してモジュールが一度だけインストールされることを保証
• Nuxtフックを自動的に登録
• モジュールメタに基づいて互換性の問題を自動的にチェック
• Nuxtの内部使用のためにgetOptionsとgetMetaを公開
• 最新バージョンの@nuxt/kitからdefineNuxtModuleを使用している限り、後方および上方互換性を保証
• モジュールビルダーツールとの統合

ランタイムディレクトリ

モジュールは、Nuxt設定内の他のすべてと同様に、アプリケーションのランタイムに含まれません。ただし、モジュールをインストールしたアプリケーションにランタイムコードを提供または注入したい場合があります。それがランタイムディレクトリの役割です。

ランタイムディレクトリ内では、Nuxtアプリに関連するあらゆる種類のアセットを提供できます：

• Vueコンポーネント
• コンポーザブル
• Nuxtプラグイン

サーバーエンジンNitroには：

• APIルート
• ミドルウェア
• Nitroプラグイン

または、ユーザーのNuxtアプリケーションに注入したい他の種類のアセット：

• スタイルシート
• 3Dモデル
• 画像
• など

これらのアセットをすべてアプリケーション内に注入することができます。モジュール定義から。

ツール

モジュールには、その開発を支援するための一連のファーストパーティツールが付属しています。

@nuxt/module-builder

Nuxt Module Builderは、モジュールをビルドして出荷するためのゼロ設定のビルドツールで、すべての重労働を引き受けます。Nuxtアプリケーションとの適切な互換性を確保します。

@nuxt/kit

Nuxt Kitは、モジュールがNuxtアプリケーションと対話するのを助けるためのコンポーザブルユーティリティを提供します。可能な限り手動の代替手段よりもNuxt Kitユーティリティを使用することをお勧めします。これにより、モジュールの互換性とコードの可読性が向上します。

@nuxt/test-utils

Nuxt Test Utilsは、モジュールテスト内でNuxtアプリケーションをセットアップして実行するのを助けるユーティリティのコレクションです。

レシピ

ここでは、モジュールを作成する際に使用される一般的なパターンを紹介します。

Nuxt設定の変更

Nuxt設定はモジュールによって読み取られ、変更されることがあります。以下は、実験的な機能を有効にするモジュールの例です。

import { defineNuxtModule } from '@nuxt/kit'

export default defineNuxtModule({
  setup (options, nuxt) {
    // `experimental`オブジェクトがまだ存在しない場合は作成します
    nuxt.options.experimental ||= {}
    nuxt.options.experimental.componentIslands = true
  }
})

より複雑な設定の変更を処理する必要がある場合は、defuを使用することを検討してください。

ランタイムへのオプションの公開

モジュールはアプリケーションのランタイムの一部ではないため、そのオプションもランタイムの一部ではありません。ただし、多くの場合、ランタイムコード内でこれらのモジュールオプションの一部にアクセスする必要があります。NuxtのruntimeConfigを使用して必要な設定を公開することをお勧めします。

import { defineNuxtModule } from '@nuxt/kit'
import { defu } from 'defu'

export default defineNuxtModule({
  setup (options, nuxt) {
    nuxt.options.runtimeConfig.public.myModule = defu(nuxt.options.runtimeConfig.public.myModule, {
      foo: options.foo
    })
  }
})

ユーザーが提供するパブリックランタイム設定を上書きするのではなく、defuを使用して拡張していることに注意してください。

その後、プラグイン、コンポーネント、アプリケーション内で他のランタイム設定と同様にモジュールオプションにアクセスできます：

const options = useRuntimeConfig().public.myModule

addPluginを使用したプラグインの注入

プラグインは、モジュールがランタイムロジックを追加する一般的な方法です。addPluginユーティリティを使用して、モジュールからプラグインを登録できます。

import { defineNuxtModule, addPlugin, createResolver } from '@nuxt/kit'

export default defineNuxtModule({
  setup (options, nuxt) {
    // 相対パスを解決するためのリゾルバを作成
    const resolver = createResolver(import.meta.url)

    addPlugin(resolver.resolve('./runtime/plugin'))
  }
})

addComponentを使用したVueコンポーネントの注入

モジュールがVueコンポーネントを提供する必要がある場合、addComponentユーティリティを使用して、Nuxtが解決するための自動インポートとして追加できます。

import { defineNuxtModule, addComponent } from '@nuxt/kit'

export default defineNuxtModule({
  setup(options, nuxt) {
    const resolver = createResolver(import.meta.url)

    // ランタイムディレクトリから
    addComponent({
      name: 'MySuperComponent', // vueテンプレートで使用されるコンポーネントの名前
      export: 'MySuperComponent', // （オプション）コンポーネントが名前付き（デフォルトではない）エクスポートの場合
      filePath: resolver.resolve('runtime/components/MySuperComponent.vue')
    })

    // ライブラリから
    addComponent({
      name: 'MyAwesomeComponent', // vueテンプレートで使用されるコンポーネントの名前
      export: 'MyAwesomeComponent', // （オプション）コンポーネントが名前付き（デフォルトではない）エクスポートの場合
      filePath: '@vue/awesome-components'
    })
  }
})

または、addComponentsDirを使用してディレクトリ全体を追加することもできます。

import { defineNuxtModule, addComponentsDir } from '@nuxt/kit'

export default defineNuxtModule({
  setup(options, nuxt) {
    const resolver = createResolver(import.meta.url)

    addComponentsDir({
      path: resolver.resolve('runtime/components')
    })
  }
})

addImportsとaddImportsDirを使用したコンポーザブルの注入

モジュールがコンポーザブルを提供する必要がある場合、addImportsユーティリティを使用して、Nuxtが解決するための自動インポートとして追加できます。

import { defineNuxtModule, addImports, createResolver } from '@nuxt/kit'

export default defineNuxtModule({
  setup(options, nuxt) {
    const resolver = createResolver(import.meta.url)

    addImports({
      name: 'useComposable', // 使用されるコンポーザブルの名前
      as: 'useComposable',
      from: resolver.resolve('runtime/composables/useComposable') // コンポーザブルのパス
    })
  }
})

または、addImportsDirを使用してディレクトリ全体を追加することもできます。

import { defineNuxtModule, addImportsDir, createResolver } from '@nuxt/kit'

export default defineNuxtModule({
  setup(options, nuxt) {
    const resolver = createResolver(import.meta.url)

    addImportsDir(resolver.resolve('runtime/composables'))
  }
})

addServerHandlerを使用したサーバールートの注入

import { defineNuxtModule, addServerHandler, createResolver } from '@nuxt/kit'

export default defineNuxtModule({
  setup(options, nuxt) {
    const resolver = createResolver(import.meta.url)

    addServerHandler({
      route: '/api/hello',
      handler: resolver.resolve('./runtime/server/api/hello/index.get')
    })
  }
})

動的なサーバールートを追加することもできます：

import { defineNuxtModule, addServerHandler, createResolver } from '@nuxt/kit'

export default defineNuxtModule({
  setup(options, nuxt) {
    const resolver = createResolver(import.meta.url)

    addServerHandler({
      route: '/api/hello/:name',
      handler: resolver.resolve('./runtime/server/api/hello/[name].get')
    })
  }
})

他のアセットの注入

モジュールが他の種類のアセットを提供する必要がある場合、それらも注入できます。以下は、Nuxtのcss配列を通じてスタイルシートを注入するシンプルなモジュールの例です。

import { defineNuxtModule, addPlugin, createResolver } from '@nuxt/kit'

export default defineNuxtModule({
  setup (options, nuxt) {
    const resolver = createResolver(import.meta.url)

    nuxt.options.css.push(resolver.resolve('./runtime/style.css'))
  }
})

そして、NitroのpublicAssetsオプションを通じてアセットのフォルダを公開するより高度な例：

import { defineNuxtModule, createResolver } from '@nuxt/kit'

export default defineNuxtModule({
  setup (options, nuxt) {
    const resolver = createResolver(import.meta.url)

    nuxt.hook('nitro:config', async (nitroConfig) => {
      nitroConfig.publicAssets ||= []
      nitroConfig.publicAssets.push({
        dir: resolver.resolve('./runtime/public'),
        maxAge: 60 * 60 * 24 * 365 // 1年
      })
    })
  }
})

モジュール内で他のモジュールを使用する

モジュールが他のモジュールに依存している場合、Nuxt KitのinstallModuleユーティリティを使用してそれらを追加できます。たとえば、モジュール内でNuxt Tailwindを使用したい場合、以下のように追加できます：

import { defineNuxtModule, createResolver, installModule } from '@nuxt/kit'

export default defineNuxtModule<ModuleOptions>({
  async setup (options, nuxt) {
    const resolver = createResolver(import.meta.url)

    // Tailwindのディレクティブを含むCSSファイルを注入できます
    nuxt.options.css.push(resolver.resolve('./runtime/assets/styles.css'))

    await installModule('@nuxtjs/tailwindcss', {
      // モジュール設定
      exposeConfig: true,
      config: {
        darkMode: 'class',
        content: {
          files: [
            resolver.resolve('./runtime/components/**/*.{vue,mjs,ts}'),
            resolver.resolve('./runtime/*.{mjs,js,ts}')
          ]
        }
      }
    })
  }
})

フックの使用

ライフサイクルフックを使用すると、Nuxtのほぼすべての側面を拡張できます。モジュールはプログラム的に、または定義内のhooksマップを通じてフックすることができます。

import { defineNuxtModule, addPlugin, createResolver } from '@nuxt/kit'

export default defineNuxtModule({
  // `hooks`マップを通じて`app:error`フックにフック
  hooks: {
    'app:error': (err) => {
      console.info(`This error happened: ${err}`);
    }
  },
  setup (options, nuxt) {
    // プログラム的に`pages:extend`フックにフック
    nuxt.hook('pages:extend', (pages) => {
      console.info(`Discovered ${pages.length} pages`);
    })
  }
})

import { defineNuxtModule } from '@nuxt/kit'

export default defineNuxtModule({
  setup (options, nuxt) {
    nuxt.hook('close', async nuxt => {
      // カスタムコードをここに
    })
  }
})

テンプレート/仮想ファイルの追加

ユーザーのアプリにインポートできる仮想ファイルを追加する必要がある場合、addTemplateユーティリティを使用できます。

import { defineNuxtModule, addTemplate } from '@nuxt/kit'

export default defineNuxtModule({
  setup (options, nuxt) {
    // ファイルはNuxtの内部仮想ファイルシステムに追加され、'#build/my-module-feature.mjs'からインポートできます
    addTemplate({
      filename: 'my-module-feature.mjs',
      getContents: () => 'export const myModuleFeature = () => "hello world !"'
    })
  }
})

サーバー用には、代わりにaddServerTemplateユーティリティを使用する必要があります。

import { defineNuxtModule, addServerTemplate } from '@nuxt/kit'

export default defineNuxtModule({
  setup (options, nuxt) {
    // ファイルはNitroの仮想ファイルシステムに追加され、サーバーコードから'my-server-module.mjs'としてインポートできます
    addServerTemplate({
      filename: 'my-server-module.mjs',
      getContents: () => 'export const myServerModule = () => "hello world !"'
    })
  }
})

型宣言の追加

ユーザーのプロジェクトに型宣言を追加したい場合（例えば、Nuxtインターフェースを拡張したり、独自のグローバル型を提供したりする場合）、NuxtはaddTypeTemplateユーティリティを提供しており、これによりテンプレートをディスクに書き込み、生成されたnuxt.d.tsファイルに参照を追加します。

モジュールがNuxtによって処理される型を拡張する必要がある場合、addTypeTemplateを使用してこの操作を実行できます：

import { defineNuxtModule, addTemplate, addTypeTemplate } from '@nuxt/kit'

export default defineNuxtModule({
  setup (options, nuxt) {
    addTypeTemplate({
      filename: 'types/my-module.d.ts',
      getContents: () => `// Generated by my-module
        interface MyModuleNitroRules {
          myModule?: { foo: 'bar' }
        }
        declare module 'nitropack' {
          interface NitroRouteRules extends MyModuleNitroRules {}
          interface NitroRouteConfig extends MyModuleNitroRules {}
        }
        export {}`
    })
  }
})

より細かい制御が必要な場合は、prepare:typesフックを使用して、型を注入するコールバックを登録できます。

const template = addTemplate({ /* template options */ })
nuxt.hook('prepare:types', ({ references }) => {
  references.push({ path: template.dst })
})

テンプレートの更新

テンプレート/仮想ファイルを更新する必要がある場合、updateTemplatesユーティリティを次のように活用できます：

nuxt.hook('builder:watch', async (event, path) => {
  if (path.includes('my-module-feature.config')) {
    // 登録したテンプレートをリロードします
    updateTemplates({ filter: t => t.filename === 'my-module-feature.mjs' })
  }
})

テスト

テストは、さまざまなセットアップでモジュールが期待通りに動作することを確認するのに役立ちます。このセクションでは、モジュールに対してさまざまな種類のテストを実行する方法を紹介します。

単体テストと統合テスト

エンドツーエンド

Nuxt Test Utilsは、モジュールをエンドツーエンドでテストするためのライブラリです。以下はそれを使用するためのワークフローです：

1. test/fixtures/*内に"フィクスチャ"として使用するNuxtアプリケーションを作成します
2. テストファイル内でこのフィクスチャを使用してNuxtをセットアップします
3. @nuxt/test-utilsからのユーティリティを使用してフィクスチャと対話します（例：ページをフェッチする）
4. このフィクスチャに関連するチェックを実行します（例："HTMLに...が含まれている"）
5. 繰り返します

実際のフィクスチャ：

// 1. フィクスチャとして使用するNuxtアプリケーションを作成
import MyModule from '../../../src/module'

export default defineNuxtConfig({
  ssr: true,
  modules: [
    MyModule
  ]
})

そしてそのテスト：

import { describe, it, expect } from 'vitest'
import { fileURLToPath } from 'node:url'
import { setup, $fetch } from '@nuxt/test-utils/e2e'

describe('ssr', async () => {
  // 2. テストファイル内でこのフィクスチャを使用してNuxtをセットアップ
  await setup({
    rootDir: fileURLToPath(new URL('./fixtures/ssr', import.meta.url)),
  })

  it('renders the index page', async () => {
    // 3. `@nuxt/test-utils`からのユーティリティを使用してフィクスチャと対話
    const html = await $fetch('/')

    // 4. このフィクスチャに関連するチェックを実行
    expect(html).toContain('<div>ssr</div>')
  })
})

// 5. 繰り返します
describe('csr', async () => { /* ... */ })

Playgroundと外部での手動QA

モジュールを開発する際にテストするためのPlayground Nuxtアプリケーションを持つことは非常に便利です。モジュールスターターにはその目的のために統合されています。

モジュールを他のNuxtアプリケーション（モジュールリポジトリの一部ではないアプリケーション）でローカルにテストすることができます。これを行うには、npm packコマンド、またはパッケージマネージャーの同等のコマンドを使用して、モジュールからtarballを作成します。その後、テストプロジェクトで、package.jsonのパッケージとしてモジュールを次のように追加できます："my-module": "file:/path/to/tarball.tgz"。

その後、通常のプロジェクトのようにmy-moduleを参照できるはずです。

ベストプラクティス

大きな力には大きな責任が伴います。モジュールは強力ですが、アプリケーションのパフォーマンスを維持し、開発者の体験を向上させるために、モジュールを作成する際に心に留めておくべきベストプラクティスを以下に示します。

非同期モジュール

見てきたように、Nuxtモジュールは非同期であることができます。たとえば、APIをフェッチしたり、非同期関数を呼び出す必要があるモジュールを開発したい場合があります。

ただし、非同期の動作には注意が必要です。Nuxtは、次のモジュールに進んで開発サーバーの開始やビルドプロセスを開始する前に、モジュールのセットアップを待ちます。時間のかかるロジックはNuxtフックに遅延させることをお勧めします。

露出するインターフェースには常にプレフィックスを付ける

Nuxtモジュールは、他のモジュールや内部と競合しないように、露出する設定、プラグイン、API、コンポーザブル、またはコンポーネントに明示的なプレフィックスを提供する必要があります。

理想的には、モジュールの名前でプレフィックスを付けるべきです（例：モジュールがnuxt-fooと呼ばれる場合、<FooButton>とuseFooBar()を公開し、<Button>とuseBar()を公開しない）。

TypeScriptに優しい

Nuxtは、最高の開発者体験のためにTypeScriptを第一級で統合しています。

型を公開し、TypeScriptを使用してモジュールを開発することは、直接TypeScriptを使用していない場合でもユーザーに利益をもたらします。

CommonJS構文を避ける

NuxtはネイティブESMに依存しています。詳細についてはネイティブESモジュールをお読みください。

モジュールの使用法を文書化する

モジュールの使用法をreadmeファイルに文書化することを検討してください：

• なぜこのモジュールを使用するのか？
• このモジュールをどのように使用するのか？
• このモジュールは何をするのか？

統合ウェブサイトとドキュメントへのリンクを追加することは常に良いアイデアです。

StackBlitzデモまたはボイラープレートを提供する

モジュールとStackBlitzを使用した最小限の再現を作成し、モジュールのreadmeに追加することは良いプラクティスです。

これは、モジュールの潜在的なユーザーにモジュールを簡単に試す方法を提供するだけでなく、問題が発生したときに最小限の再現を作成して送信する簡単な方法も提供します。

特定のNuxtバージョンで宣伝しない

Nuxt、Nuxt Kit、および他の新しいツールは、前方および後方互換性を念頭に置いて作られています。

エコシステムの断片化を避けるために、「Nuxt用のX」を使用し、「Nuxt 3用のX」を使用しないでください。また、Nuxtバージョンの制約を設定するためにmeta.compatibilityを使用することをお勧めします。

スターターデフォルトに従う

モジュールスターターには、デフォルトのツールと設定（例：ESLint設定）が付属しています。モジュールをオープンソース化する予定がある場合、これらのデフォルトに従うことで、他のコミュニティモジュールと一貫したコーディングスタイルを共有し、他の人が貢献しやすくなります。

エコシステム

Nuxtモジュールエコシステムは、月間1500万以上のNPMダウンロードを誇り、さまざまなツールとの拡張機能と統合を提供しています。あなたもこのエコシステムの一部になることができます！

モジュールの種類

公式モジュールは、@nuxt/（例：@nuxt/content）でプレフィックス（スコープ）されたモジュールです。これらはNuxtチームによって作成され、積極的にメンテナンスされています。フレームワークと同様に、コミュニティからの貢献は大歓迎で、より良いものにするために役立ちます！

コミュニティモジュールは、@nuxtjs/（例：@nuxtjs/tailwindcss）でプレフィックス（スコープ）されたモジュールです。これらは、コミュニティメンバーによって作成され、メンテナンスされている実績のあるモジュールです。ここでも、誰からの貢献も歓迎されます。

サードパーティおよびその他のコミュニティモジュールは、（多くの場合）nuxt-でプレフィックスされたモジュールです。誰でもこれらを作成でき、このプレフィックスを使用することで、これらのモジュールはnpmで発見可能になります。アイデアをドラフトし、試すための最良の出発点です！

プライベートまたは個人用モジュールは、独自のユースケースや会社のために作成されたモジュールです。これらはNuxtと連携するために特定の命名規則に従う必要はなく、npm組織（例：@my-company/nuxt-auth）の下にスコープされることがよくあります。

コミュニティモジュールのリスト化

コミュニティモジュールはすべてモジュールリストにリストされることを歓迎します。リストされるには、nuxt/modulesリポジトリでissueを開いてください。Nuxtチームはリスト化前にベストプラクティスを適用するのを手伝います。

nuxt-modulesと@nuxtjs/への参加

モジュールをnuxt-modulesに移動することで、常に誰かが助けてくれるようになり、この方法で完璧なソリューションを作るために力を合わせることができます。

すでに公開され、動作しているモジュールを持っていて、それをnuxt-modulesに移行したい場合、nuxt/modulesでissueを開いてください。

nuxt-modulesに参加することで、コミュニティモジュールを@nuxtjs/スコープの下にリネームし、そのドキュメントのためにサブドメイン（例：my-module.nuxtjs.org）を提供できます。