nx-generate
nx generatorsを使用してコードを生成します。ユーザーがスカフォルディング、セットアップ、構造化、アプリ/ライブラリの作成、またはプロジェクト構造の設定について言及した場合は即座に実行してください。トリガーワード:scaffold、setup、create a ... app、create a ... lib、project structure、generate、add a new projectなど。このスキルは内部で探索を処理するため、nx_docsの呼び出しやその他の探索を行う前に必ず使用してください。
description の原文を見る
Generate code using nx generators. INVOKE IMMEDIATELY when user mentions scaffolding, setup, structure, creating apps/libs, or setting up project structure. Trigger words - scaffold, setup, create a ... app, create a ... lib, project structure, generate, add a new project. ALWAYS use this BEFORE calling nx_docs or exploring - this skill handles discovery internally.
SKILL.md 本文
Nx ジェネレーターを実行
Nx ジェネレーターは、プロジェクトをスカフォールディングしたり、自動化されたコード移行を行ったり、モノレポ内の反復的なタスクを自動化したりする強力なツールです。コードベース全体の一貫性を保証し、ボイラープレート作業を削減します。
このスキルが適用される場合:
- ライブラリまたはアプリケーションなどの新しいプロジェクトを作成したい
- 機能またはボイラープレートコードをスカフォールディングしたい
- ワークスペース固有またはカスタムジェネレーターを実行したい
- nx ジェネレーターが存在するその他のことを行いたい
主要な原則
- 必ず
--no-interactiveを使用 - 実行をハングさせるプロンプトを防ぎます - ジェネレーターソースコードを読む - スキーマだけでは不十分です。ジェネレーターが実際に何をするのかを理解してください
- 既存のリポジトリパターンに合わせる - リポジトリ内の同様のアーティファクトを研究し、その規約に従ってください
- lint/test/build/typecheck などで検証する - 生成されたコードは検証に合格する必要があります。リストされたターゲットは単なる例です。このワークスペースに適切なものを使用してください。
ステップ
1. 利用可能なジェネレーターを発見
Nx CLI を使用して利用可能なジェネレーターを発見します:
- プラグインのすべてのジェネレーターをリストアップ:
npx nx list @nx/react - 利用可能なプラグインを表示:
npx nx list
これには、プラグインジェネレーター (例: @nx/react:library) とローカルワークスペースジェネレーターが含まれます。
2. ジェネレーターをユーザーリクエストに合わせる
ユーザーのニーズを満たすことができるジェネレーターを特定します。必要なアーティファクトタイプ、関連するフレームワーク、言及されている特定のジェネレーター名を検討してください。
重要: ローカルワークスペースジェネレーターと外部プラグインジェネレーターの両方がリクエストを満たす可能性がある場合、常にローカルワークスペースジェネレーターを優先してください。ローカルジェネレーターは、特定のリポジトリのパターン用にカスタマイズされています。
適切なジェネレーターが存在しない場合、このスキルの使用を停止できます。ただし、証拠の負担は高いため、適切なジェネレーターがないと判断する前に、利用可能なすべてのジェネレーターを慎重に検討してください。
3. ジェネレーターオプションを取得
--help フラグを使用して利用可能なオプションを理解します:
npx nx g @nx/react:library --help
必須オプション、オーバーライドする可能性があるデフォルト、ユーザーのリクエストに関連するオプションに注意してください。
ライブラリのビルド可能性
特別な理由がない限り、ビルド不可能なライブラリをデフォルトにしてください。
| タイプ | 使用する場合 | ジェネレーターフラグ |
|---|---|---|
| ビルド不可能 (デフォルト) | アプリによって使用される内部モノレポライブラリ | --bundler フラグなし |
| ビルド可能 | npm への公開、クロスリポ共有、キャッシュヒット用の安定ライブラリ | --bundler=vite または --bundler=swc |
ビルド不可能なライブラリ:
.ts/.tsxソースを直接エクスポート- コンシューマーのバンドラーがそれらをコンパイル
- より高速な開発体験、より少ない設定
ビルド可能なライブラリ:
- 独自のビルドターゲットを持つ
- めったに変わらない安定ライブラリに有用 (キャッシュヒット)
- npm 公開に必須
不明な場合、ユーザーに尋ねてください: 「このライブラリはビルド可能 (独自のビルドステップ、より良いキャッシング) にすべき、それともビルド不可能 (ソースが直接使用される、よりシンプルなセットアップ) にすべきですか?」
4. ジェネレーターソースコードを読む
このステップは重要です。 スキーマだけではすべてを伝えません。ソースコードを読むことで以下が可能になります:
- 作成/変更されるファイルとその場所を正確に把握
- 副作用 (設定の更新、依存関係のインストール など) を理解
- スキーマから明らかでない動作とオプションを特定
- オプションがどのように相互作用するかを理解
ジェネレーターソースコードを見つけるには:
- プラグインジェネレーターの場合:
node -e "console.log(require.resolve('@nx/<plugin>/generators.json'));"を使用して generators.json を見つけ、そこからソースを見つけます - それが失敗した場合:
node_modules/<plugin>/generators.jsonから直接読みます - ローカルジェネレーターの場合: 通常
tools/generators/またはローカルプラグインディレクトリにあります。ジェネレーター名でリポジトリを検索します。
ソースコードを読んだ後、再検討してください: これは正しいジェネレーターですか? そうでない場合は、ステップ 2 に戻ります。
⚠️
--directoryフラグの動作は誤解を招く可能性があります。 生成されたライブラリまたはコンポーネントの完全なパスを指定する必要があり、それが生成される親パスではありません。# ✅ 正しい - directory はライブラリの完全なパス nx g @nx/react:library --directory=libs/my-lib # libs/my-lib/package.json などを生成 # ❌ 誤り - これにより libs と libs/src/... にファイルが作成されます nx g @nx/react:library --name=my-lib --directory=libs # libs/package.json などを生成
5. 既存パターンを検査
生成する前に、コードベースのターゲット領域を検査します:
- 同様の既存アーティファクト (他のライブラリ、アプリケーション など) を見て
- 命名規約、ファイル構造、設定パターンを特定
- 使用されているテストランナー、ビルドツール、リンターを注記
- これらのパターンに合わせてジェネレーターを設定
6. ドライランでファイル配置を検証
ファイルが正しい場所に作成されることを確認するため、常に --dry-run で最初に実行してください:
npx nx g @nx/react:library --name=my-lib --dry-run --no-interactive
出力を注意深く確認してください。ファイルが間違った場所に作成される場合は、ジェネレーターソースコードから学んだことに基づいてオプションを調整してください。
注記: 一部のジェネレーターはドライランをサポートしていません (例: npm パッケージをインストールする場合)。この理由でドライランが失敗した場合は、ジェネレーターを実際に実行してください。
7. ジェネレーターを実行
ジェネレーターを実行します:
nx generate <generator-name> <options> --no-interactive
ヒント: 新しいパッケージには、ワークスペース依存関係の配線が必要なことが多いです (例: 共有型のインポート、アプリによる使用)。
link-workspace-packagesスキルがこれらを正しく追加するのに役立ちます。
8. 生成されたコードを変更 (必要な場合)
ジェネレーターは出発点を提供します。以下を行うために出力を変更してください:
- リクエストされた機能を追加または変更
- インポート、エクスポート、または構成を調整
- 既存のコードパターンと統合
重要: 生成されたテストファイル (例: *.spec.ts) を置き換えたり削除したりする場合、意味のある代替テストを作成するか、プロジェクト構成から test ターゲットを削除してください。空のテストスイートは nx test を失敗させます。
9. フォーマットと検証
生成/変更されたすべてのファイルをフォーマットします:
nx format --fix
この例は、prettier を使用した組み込みの nx フォーマット用です。このワークスペースには他のフォーマッションツールがある可能性があります。適切な場合にこれらを使用してください。
次に、生成されたコードが機能することを確認します。ジェネレーターで行った変更または後続の変更が様々なプロジェクトに影響を与える可能性があるため、作成したばかりのアーティファクト用のターゲットのみを実行するだけでは通常は不十分です。
# これらのターゲットは単なる例です!
nx run-many -t build,lint,test,typecheck
これらのターゲットは、多くのワークスペース全体で使用される一般的な例です。このワークスペースとそのプロジェクトで利用可能な他のターゲットについて調査を行うべきです。CI 設定は通常、合格する必要がある重要なターゲットが何であるかの良いガイドです。
検証がいくつかの lint エラーや軽微な型の問題で失敗した場合、それらを修正してください。問題が広範な場合、明白な修正を最初に試行し、生成内容、失敗内容、試行したことの詳細についてユーザーにエスカレーションしてください。
ライセンス: Apache-2.0(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- storm-software
- ライセンス
- Apache-2.0
- 最終更新
- 2026/5/5
Source: https://github.com/storm-software/powerlines / ライセンス: Apache-2.0