コードスタイル
NuxtはESLintを標準でサポートしています
ESLint
Nuxtの推奨アプローチは、@nuxt/eslintモジュールを使用してESLintサポートを有効にすることです。これにより、プロジェクトに適したESLint設定が自動的にセットアップされます。
このモジュールは、ESLint v9以降のデフォルト形式である新しいESLintフラット設定形式用に設計されています。レガシーな.eslintrc設定を使用している場合は、@nuxt/eslint-configで手動設定する必要があります。将来に備えて、フラット設定への移行を強くお勧めします。
クイックセットアップ
npx nuxt module add eslint
Nuxtアプリを開始すると、プロジェクトのルートにeslint.config.mjsファイルが生成されます。必要に応じてカスタマイズできます。
モジュールやカスタマイズについての詳細は、Nuxt ESLintのドキュメントで学ぶことができます。
tips
このセクションは公式ドキュメントの翻訳ではなく、本サイト独自の補足記事です。
はじめに:ESLint導入で得られるメリットと解決できる課題
Nuxtは標準でESLintをサポートしており、コード品質の向上やバグの早期発見に役立ちます。ESLintを適切に導入することで、チーム開発におけるコードの一貫性を保ち、保守性を高めることが可能です。
しかし、ESLintの設定や運用は初心者にとっては敷居が高く、誤った設定や運用方法では逆に開発効率を下げてしまうこともあります。そこで本記事では、Nuxt公式のESLintサポートを補完し、実務での具体的な活用方法や注意点を丁寧に解説します。
まず結論:NuxtでESLintを使う際のポイント
- Nuxt公式の
@nuxt/eslintモジュールを使うと、最適化されたESLint設定が自動生成される - ESLintの新しいフラット設定形式に対応しており、将来的なメンテナンス性が高い
- チーム開発ではルールのカスタマイズや共有設定を活用し、一貫性を保つことが重要
- 実務ではコードの静的解析だけでなく、フォーマットや自動修正も組み合わせると効果的
- SSRやHydrationの特性を理解し、Nuxt特有のコードパターンに対応したルール設定が必要
いつ使うべきか・使わない方がよいケース
使うべきケース
- 複数人でのNuxtプロジェクト開発時にコード品質を担保したい場合
- 新規プロジェクトで初期段階からコードスタイルを統一したい場合
- CI/CDパイプラインに静的解析を組み込み、品質チェックを自動化したい場合
- Nuxtの最新機能やESLintの新しい設定形式を活用して将来の保守性を高めたい場合
使わない方がよいケース
- 小規模な個人プロジェクトで設定や運用コストが割に合わない場合
- 既存のレガシーなESLint設定をすぐにフラット形式に移行できない場合(移行計画を立てることを推奨)
- ESLintの警告やエラーが多すぎて開発が停滞する場合(ルールの見直しや段階的導入が必要)
実務でよくあるユースケースとサンプルコード
1. 新規NuxtプロジェクトでのESLint導入
npx nuxt module add eslint
このコマンドでeslint.config.mjsが自動生成され、Nuxtに最適化されたESLint設定が適用されます。初期設定のままでも十分ですが、プロジェクトの要件に応じてルールをカスタマイズ可能です。
2. チームでのルール共有とカスタマイズ
eslint.config.mjs内でルールを追加・変更し、Gitで共有します。例えば、コードのインデント幅やセミコロンの有無など、チームのコーディング規約に合わせて調整します。
export default {
rules: {
'semi': ['error', 'always'],
'indent': ['error', 2],
}
}
3. CI/CDパイプラインでの自動チェック
GitHub ActionsやGitLab CIなどにESLintチェックを組み込み、プルリクエスト時にコード品質を自動検証します。これにより、問題のあるコードが本番環境に入るのを防げます。
# GitHub Actionsの例
jobs:
lint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Setup Node.js
uses: actions/setup-node@v3
with:
node-version: 18
- run: npm install
- run: npx eslint .
よくある落とし穴・注意点
SSRとHydrationの観点
NuxtはSSR(サーバーサイドレンダリング)を行うため、クライアントとサーバーでコードが異なる場合があります。ESLintルールは両方の環境を考慮して設定しないと、サーバー専用のコードやクライアント専用のコードで誤検知が発生することがあります。
パフォーマンスへの影響
ESLintの実行は開発時のビルドやCIの時間に影響します。特に大規模プロジェクトでは、対象ファイルを限定したり、キャッシュを活用するなどの工夫が必要です。
新しいフラット設定形式への移行
Nuxt公式はESLintの新しいフラット設定形式を推奨していますが、既存の.eslintrc形式からの移行は慎重に行いましょう。移行中は両方の設定が混在しないよう注意が必要です。
まとめ
NuxtのESLintサポートは、コード品質向上と開発効率化に大きく貢献します。公式の@nuxt/eslintモジュールを活用し、プロジェクトに最適なルールを設定することで、チーム全体の生産性とコードの保守性を高められます。SSR特有の注意点やパフォーマンス面も理解し、段階的かつ計画的に導入・運用することが成功の鍵です。
ESLintは単なる静的解析ツールではなく、チームのコーディング文化を形成する重要な要素です。Nuxtの最新機能と組み合わせて、より良い開発体験を目指しましょう。
※このページは Nuxt.js 公式ドキュメントの翻訳ページです。
公式ドキュメントの該当ページはこちら:
https://nuxt.com/docs/3.x/guide/concepts/code-style