ワークスペース

@aws/nx-pluginで新しいワークスペースを作成すると、プリセットジェネレーターがAWS上での構築に適した合理的なデフォルト設定でNxモノレポをセットアップします。

ワークスペースの作成

ワークスペースを作成@aws/nx-workspace

$ pnpm create @aws/nx-workspace my-project

$ yarn create @aws/nx-workspace my-project

$ npm create @aws/nx-workspace -- my-project

$ bun create @aws/nx-workspace my-project

コマンドを組み立てる8

workspace必須

iac

containers

gitSecrets

true

mcp

true

module

catalog

true

preferInstallDependencies

true

オプション

ジェネレーターオプション7 オプション

iacenumデフォルト: cdk: 優先するIaCプロバイダー。
cdkterraform
containersenumデフォルト: infer: ビルド/プッシュ/ログインに使用するコンテナエンジン。'infer'はdockerがインストールされている場合はdockerを選択し、それ以外の場合はfinchを選択します（どちらもインストールされていない場合はdockerにフォールバックします）。
inferdockerfinch
gitSecretsbooleanデフォルト: true: AWSの認証情報のコミットを防ぐためにgit-secretsを設定するかどうか。
mcpbooleanデフォルト: true: コーディングエージェントが使用するためのAWS MCP サーバー用 Nx Plugin を設定するかどうか。
moduleenumデフォルト: esm: 生成されるTypeScriptコードと設定のモジュール形式。
esmcjs
catalogbooleanデフォルト: true: ジェネレーターが依存関係のバージョンをパッケージマネージャーのカタログ（pnpm/yarn/bun）に記録するかどうか。バージョンの単一の情報源を維持します。falseの場合、依存関係は各プロジェクトのpackage.jsonに直接書き込まれ、バージョンの整合性を保つことはあなたの責任となります。
preferInstallDependenciesbooleanデフォルト: true: ジェネレーター実行後に依存関係のインストールを優先するかどうか。複数のジェネレーターをバッチ処理する際にインストールを延期する場合はfalseに設定します（後続のジェネレーターがNxプロジェクトグラフを計算できるよう、必要に応じてインストールは実行されます）。最後に一度だけインストールします。

ワークスペース構造

Directorypackages/ Your projects live here
- …
package.json Root package.json for your monorepo
nx.json Nx configuration (common targets, sync generators, caching)
tsconfig.base.json Root TypeScript configuration
biome.json Biome configuration for linting and formatting
aws-nx-plugin.config.mts Nx Plugin for AWS configuration
Directory.git-secrets/ Vendored git-secrets bash script for credential scanning
- …
.gitallowed Patterns git-secrets treats as false positives
Directory.husky/ Git hooks
- …
.mcp.json Nx Plugin for AWS MCP server configuration for Claude Code
.cursor/mcp.json …and for Cursor
.kiro/settings/mcp.json …and for Kiro
.gemini/settings.json …and for Gemini CLI
.vscode/mcp.json …and for GitHub Copilot
.codex/config.toml …and for OpenAI Codex

Nx

Nxは、モノレポ向けの言語非依存のビルドシステムで、任意のプログラミング言語で書かれたプロジェクト間の依存関係とそれらをビルドするタスクを管理します。詳細はNxウェブサイトで確認できます。

プロジェクト

Nxモノレポは1つ以上のプロジェクトで構成され、各プロジェクトにはproject.jsonファイルがあります。project.jsonは、プロジェクトのタスク（_ターゲット_と呼ばれる）を定義し、プロジェクトのビルド方法、ローカル実行方法、テスト方法などを定義します。また、プロジェクト内またはプロジェクト間のターゲット間の依存関係も定義します。

例えば、project.jsonは、すべての上流プロジェクトが最初にビルドされることに依存するbuildターゲットを定義する場合があります：

{
  "name": "@my-workspace/my-project",
  "targets": {
    "build": {
      "executor": "@nx/js:tsc",
      "dependsOn": ["^build"]
    },
    "test": {
      "command": "vitest run"
    }
  }
}

TypeScriptおよびPythonプロジェクトのセットアップ方法の詳細については、ts#projectおよびpy#projectジェネレーターガイドを参照してください。

キャッシング

Nxは、以前に実行されたターゲットの出力をキャッシュし、入力が変更されていない場合にそれらを再生します。これにより、ビルド、テスト、リンティングが劇的に高速化されます。古いまたは予期しない動作が発生した場合は、次のコマンドでキャッシュをリセットしてください：

pnpm nx reset

yarn nx reset

npx nx reset

bunx nx reset

詳細については、Nxキャッシングドキュメントを参照してください。

並列処理

新しいワークスペースはnx.jsonにparallelを設定しており、これはNxが同時に実行するタスクの数を制御します：

{
  "parallel": 8
}

コア数が少ないマシンやメモリが限られている場合は、これを下げてください。また、実行ごとにオーバーライドすることもできます：

pnpm nx run-many --target build --parallel=4

yarn nx run-many --target build --parallel=4

npx nx run-many --target build --parallel=4

bunx nx run-many --target build --parallel=4

単一バージョンポリシー

デフォルトのモノレポセットアップは、NodeとPythonベースのプロジェクトの両方に対して単一バージョンポリシーを使用します。

これは、モノレポ内のすべてのプロジェクトがデフォルトで同じバージョンの依存関係を使用することを意味し、同じモノレポ内のパッケージがバージョンの不一致の問題に遭遇することを減らします。

Nodeの観点からは、これはルートに単一のロックファイルがあり、依存関係が一度インストールされ、各プロジェクトにリンクされることを意味します。各Nodeプロジェクトは、そのソースがインポートするランタイム依存関係を独自のpackage.jsonで宣言し、共有のビルド/テストツールはルートのpackage.jsonのdevDependenciesに配置されます。プロジェクトのランタイム依存関係を追加するには、そのプロジェクトにインストールします：

pnpm add some-npm-package --filter my-project

yarn workspace @my-scope/my-project add some-npm-package

npm install --legacy-peer-deps some-npm-package -w packages/my-project

bun add some-npm-package --cwd packages/my-project

カタログサポートを持つパッケージマネージャー（pnpm、yarn、bun）の場合、依存関係のバージョンはカタログに記録され、catalog:プロトコルで参照されるため、すべてのプロジェクトのpackage.jsonにわたってバージョンの単一の真実の源が保たれます。npmワークスペースの場合、複数のpackage.jsonファイルにわたって宣言されたバージョンを整合させるためにsyncpackを推奨します。

Pythonの観点からは、これはモノレポのルートに単一の.venvがあり、すべての依存関係がそこにインストールされることを意味します。各Pythonプロジェクトには独自のpyproject.tomlがありますが、それらの依存関係のバージョンはUVワークスペースによって管理され、その後ルートのuv.lockファイルに書き出されます。

一般的なコマンド

ビルド

ワークスペース内のすべてのプロジェクトをビルドします：

pnpm build

yarn build

npm run build

bun build

リント

すべてのプロジェクトをリントして自動修正します：

pnpm lint

yarn lint

npm run lint

bun lint

テスト

すべてのプロジェクトでテストを実行します：

pnpm test

yarn test

npm run test

bun test

開発

ワークスペース全体のすべてのローカル開発サーバーを起動します：

pnpm dev

yarn dev

npm run dev

bun dev

詳細については、ローカル開発ガイドを参照してください。

同期

同期ジェネレーターを実行します。これは、例えばTypeScriptプロジェクト参照を同期します（詳細についてはts#projectジェネレーターガイドを参照してください）：

pnpm nx sync

yarn nx sync

npx nx sync

bunx nx sync

特定のターゲットの実行

次のコマンドで特定のプロジェクトの特定のターゲットを実行できます：

pnpm nx <target> <project>

yarn nx <target> <project>

npx nx <target> <project>

bunx nx <target> <project>

例えば：

pnpm nx build website

yarn nx build website

npx nx build website

bunx nx build website

これにより、選択したターゲットとそれが依存するターゲットが実行されます。

含まれるもの

リンティング

新しいワークスペースは、静的解析とコードフォーマットのためにBiomeで構成されています。lintを実行するとすべてのプロジェクトの問題がチェックされ、lint --configuration=fixで自動修正されます。

MCP設定

プラグインのMCPサーバーは、Claude Code、Cursor、Kiro、Gemini CLI、GitHub Copilot、OpenAI Codex用のプロジェクトレベルのMCPサーバーとして設定されているため、コーディングアシスタントはセットアップなしでプラグインのジェネレーターを検出して実行できます。設定はワークスペースとともにコミットされるため、チームの全員が同じセットアップを利用できます。あなたとあなたのチームが使用しないコーディングアシスタントの設定は削除してください。

Git Secrets

ワークスペースには、各コミット前にステージングされたファイルをAWS認証情報パターンでスキャンするgit-secretsプリコミットフックがセットアップされています。これにより、アクセスキー、シークレットキー、その他の機密値を誤ってコミットすることを防ぎます。

スクリプトは.git-secrets/git-secretsにワークスペースにベンダリングされており、.husky/pre-commitフックによって実行されるため、インストールする必要はありません。ただし、PATHには含まれていないため、git secretsとしてではなく、パスで呼び出してください。

誤検知の抑制

git-secretsのパターンはegrep互換の正規表現を使用します。git-secretsが実際の認証情報を含まないコミットをブロックする場合：

# Allow a specific regex pattern (-a is the allowed flag)
bash .git-secrets/git-secrets --add -a -- 'my-regex-pattern'

# Allow a literal string, escaping special characters (-l is the literal flag)
bash .git-secrets/git-secrets --add -a -l -- 'my-literal+string'

# List what is currently allowed
git config --get-all secrets.allowed

これらはローカルのgit設定に記録されるため、自分のクローンにのみ適用されます。抑制をチームと共有するには、代わりにリポジトリルートの.gitallowedファイルに追加してください。1行に1つのegrep互換の正規表現を記述し、<path>:<line-number>:<line-contents>に対してマッチングされます：

# Allow test fixtures
tests/fixtures/.*
# Allow a specific string
EXAMPLE[A-Z]{16}

パターン管理の詳細については、git-secretsドキュメントを参照してください。

Nx Plugin for AWS設定

ワークスペースには、ルートにaws-nx-plugin.config.mtsファイルが付属しています。ジェネレーターはこのファイルを読み取って合理的なデフォルトを選択するため、毎回同じフラグを渡す必要がありません：

// aws-nx-plugin.config.mts
import { AwsNxPluginConfig } from '@aws/nx-plugin';

export default {
  iac: {
    provider: 'cdk', // or 'terraform'
  },
  containers: {
    engine: 'docker', // or 'finch'
  },
  packageManager: {
    catalogs: true, // or false
  },
} satisfies AwsNxPluginConfig;

iac.provider — インフラストラクチャを生成するジェネレーター（例：ts#infra、ts#api、py#api）で使用されるデフォルトのインフラストラクチャ・アズ・コードプロバイダー（cdkまたはterraform）。--iacフラグを受け入れるジェネレーターは、デフォルトでinheritになっており、この値を読み取ります。
containers.engine — 生成されたビルド/プッシュ/ログインコマンドに組み込まれるコンテナCLI（dockerまたはfinch）。CDKイメージアセットビルドも、CDK_DOCKER環境変数を介してこれを取得します。詳細については、Dockerバンドリングガイドを参照してください。
packageManager.catalogs — ジェネレーターが依存関係のバージョンをパッケージマネージャーのカタログに記録し、catalog:プロトコルで参照するかどうか（単一バージョンポリシーを参照）。falseに設定すると、ジェネレーターは各プロジェクトのpackage.jsonに直接バージョン範囲を書き込みます。カタログを持たないnpmには影響しません。

licenseジェネレーターは、この同じファイルにlicenseキーを追加して、独自の動作を設定します。

いつでもどの設定も編集できます。その後のジェネレーター実行で新しい値が取得されます。