Espace de travail

Lorsque vous créez un nouvel espace de travail avec @aws/nx-plugin, le générateur de preset configure un monorepo Nx avec des valeurs par défaut sensées pour construire sur AWS.

Création d’un espace de travail

Créez votre espace de travail@aws/nx-workspace

pnpm

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

yarn

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

npm

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

bun

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

Composez votre commande8

workspaceRequis

iac

cdkterraform

containers

inferdockerfinch

gitSecrets

true

mcp

true

module

esmcjs

catalog

true

preferInstallDependencies

true

Options

Options du générateur7 options

iacenumPar défaut: cdk

Le fournisseur IaC préféré.

cdkterraform

containersenumPar défaut: infer

Le moteur de conteneurs à utiliser pour build/push/login. 'infer' choisit docker s'il est installé, sinon finch (avec repli sur docker si aucun n'est installé).

inferdockerfinch

gitSecretsbooleanPar défaut: true

Indique s'il faut configurer git-secrets pour empêcher la validation de credentials AWS.

mcpbooleanPar défaut: true

Indique s'il faut configurer le plugin Nx pour le serveur AWS MCP afin qu'il soit utilisé par les agents de codage.

moduleenumPar défaut: esm

Format de module pour le code TypeScript et la configuration générés.

esmcjs

catalogbooleanPar défaut: true

Indique si les générateurs enregistrent les versions des dépendances dans le catalogue du gestionnaire de paquets (pnpm/yarn/bun), conservant une source unique de vérité pour les versions. Lorsque false, les dépendances sont écrites directement dans le package.json de chaque projet et maintenir l'alignement des versions relève de votre responsabilité.

preferInstallDependenciesbooleanPar défaut: true

Indique s'il faut privilégier l'installation des dépendances après l'exécution du générateur. Définir sur false pour différer l'installation lors de l'exécution de plusieurs générateurs en lot (une installation s'exécute quand même si nécessaire pour que les générateurs suivants puissent calculer le graphe de projet Nx) ; installer une seule fois à la fin.

Structure de l’espace de travail

• Répertoirepackages/ 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
• Répertoire.git-secrets/ Vendored git-secrets bash script for credential scanning

  • …
• .gitallowed Patterns git-secrets treats as false positives
• Répertoire.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 est un système de build indépendant du langage pour les monorepos, gérant les dépendances entre les projets écrits dans n’importe quel langage de programmation et les tâches pour les construire. Vous pouvez en apprendre davantage sur le site web Nx.

Projets

Un monorepo Nx est composé d’un ou plusieurs projets, chacun avec un fichier project.json. Le project.json définit les tâches d’un projet, appelées targets, qui définissent comment un projet est construit, exécuté localement, testé, etc. Il définit également les dépendances entre les targets au sein d’un projet ou entre projets.

Par exemple, un project.json peut définir un target build qui dépend de la construction préalable de tous les projets en amont :

packages/my-project/project.json

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

Astuce

Pour les projets dans des langages non directement pris en charge par le Nx Plugin for AWS, vous pouvez souvent trouver un générateur dans le Nx Plugin Registry pour vous aider. Il est cependant simple d’ajouter un projet de n’importe quel langage dans votre monorepo — ajoutez simplement un fichier project.json et définissez son target build pour exécuter la commande de build spécifique pour un projet de ce langage.

Pour plus de détails sur la configuration des projets TypeScript et Python, consultez les guides des générateurs ts#project et py#project.

Mise en cache

Nx met en cache la sortie des targets précédemment exécutés et les rejoue lorsque les entrées n’ont pas changé. Cela accélère considérablement les builds, les tests et le linting. Si vous rencontrez un comportement obsolète ou inattendu, réinitialisez le cache avec :

pnpm

pnpm nx reset

yarn

yarn nx reset

npm

npx nx reset

bun

bunx nx reset

Pour plus de détails, consultez la documentation sur la mise en cache Nx.

Parallélisme

Les nouveaux espaces de travail définissent parallel dans nx.json, qui contrôle le nombre de tâches que Nx exécute simultanément :

nx.json

{
  "parallel": 8
}

Réduisez-la si vous construisez sur une machine avec moins de cœurs ou une mémoire limitée. Vous pouvez également la remplacer par invocation :

pnpm

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

yarn

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

npm

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

bun

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

Politique de version unique

La configuration par défaut du monorepo utilise une politique de version unique pour les projets basés sur Node et Python.

Cela signifie que tous les projets au sein de votre monorepo utilisent par défaut la même version des dépendances, réduisant les problèmes liés aux packages dans le même monorepo rencontrant des problèmes d’incompatibilité de version.

Du point de vue de Node, cela signifie un seul fichier de verrouillage à la racine, avec des dépendances installées une fois et liées dans chaque projet. Chaque projet Node déclare les dépendances d’exécution que son code source importe dans son propre package.json, tandis que les outils de build/test partagés résident dans les devDependencies du package.json racine. Ajoutez une dépendance d’exécution d’un projet en l’installant dans ce projet :

pnpm

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

yarn

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

npm

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

bun

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

Pour les gestionnaires de packages avec support de catalogue (pnpm, yarn et bun), les versions des dépendances sont enregistrées dans le catalogue et référencées avec le protocole catalog:, conservant une source unique de vérité pour les versions dans le package.json de chaque projet. Pour les workspaces npm, nous recommandons syncpack pour aligner les versions déclarées dans plusieurs fichiers package.json.

Du point de vue de Python, cela signifie un seul .venv à la racine du monorepo avec toutes les dépendances installées dedans. Chaque projet Python a son propre pyproject.toml, mais les versions de ces dépendances sont gérées par l’espace de travail UV et ensuite écrites dans le fichier uv.lock à la racine.

Commandes courantes

Build

Construire tous les projets dans l’espace de travail :

pnpm

pnpm build

yarn

yarn build

npm

npm run build

bun

bun build

Lint

Linter et corriger automatiquement tous les projets :

pnpm

pnpm lint

yarn

yarn lint

npm

npm run lint

bun

bun lint

Test

Exécuter les tests sur tous les projets :

pnpm

pnpm test

yarn

yarn test

npm

npm run test

bun

bun test

Dev

Démarrer tous les serveurs de développement local dans votre espace de travail :

pnpm

pnpm dev

yarn

yarn dev

npm

npm run dev

bun

bun dev

Consultez le guide Développement local pour plus de détails.

Sync

Exécuter tous les générateurs de synchronisation, qui par exemple synchronisent les références de projet TypeScript (consultez le guide du générateur ts#project pour plus de détails) :

pnpm

pnpm nx sync

yarn

yarn nx sync

npm

npx nx sync

bun

bunx nx sync

Exécuter des targets spécifiques

Vous pouvez exécuter des targets spécifiques pour des projets spécifiques avec :

pnpm

pnpm nx <target> <project>

yarn

yarn nx <target> <project>

npm

npx nx <target> <project>

bun

bunx nx <target> <project>

Par exemple :

pnpm

pnpm nx build website

yarn

yarn nx build website

npm

npx nx build website

bun

bunx nx build website

Cela exécutera le target choisi ainsi que les targets dont il dépend.

Ce qui est inclus

Linting

Les nouveaux espaces de travail sont configurés avec Biome pour l’analyse statique et le formatage du code. L’exécution de lint vérifie tous les projets pour détecter les problèmes, et lint --configuration=fix les corrige automatiquement.

Configuration MCP

Le serveur MCP du plugin est configuré en tant que serveur MCP au niveau du projet pour Claude Code, Cursor, Kiro, Gemini CLI, GitHub Copilot et OpenAI Codex, afin que votre assistant de codage puisse découvrir et exécuter les générateurs du plugin sans aucune configuration. La configuration est commitée avec votre espace de travail, donnant à tous les membres de votre équipe la même configuration. Supprimez toutes les configurations pour les assistants de codage que vous et votre équipe n’utilisez pas.

Git Secrets

Les espaces de travail sont configurés avec des hooks de pré-commit git-secrets qui analysent les fichiers mis en staging pour détecter les modèles d’identifiants AWS avant chaque commit. Cela empêche de commiter accidentellement des clés d’accès, des clés secrètes et d’autres valeurs sensibles.

Le script est intégré dans l’espace de travail à .git-secrets/git-secrets et exécuté par le hook .husky/pre-commit, il n’y a donc rien à installer — mais il n’est pas dans votre PATH, donc invoquez-le par chemin plutôt que comme git secrets.

Suppression des faux positifs

Les modèles dans git-secrets utilisent des expressions régulières compatibles egrep. Si git-secrets bloque un commit qui ne contient pas de véritables identifiants :

# 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

Ceux-ci sont enregistrés dans votre configuration git locale, ils ne s’appliquent donc qu’à votre propre clone. Pour partager une suppression avec votre équipe, ajoutez-la plutôt au fichier .gitallowed à la racine du dépôt — une regex compatible egrep par ligne, correspondant à <path>:<line-number>:<line-contents> :

.gitallowed

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

Pour tous les détails sur la gestion des modèles, consultez la documentation git-secrets.

Configuration du Nx Plugin for AWS

L’espace de travail est livré avec un fichier aws-nx-plugin.config.mts à la racine. Les générateurs lisent ce fichier pour choisir des valeurs par défaut sensées afin que vous n’ayez pas à passer les mêmes flags à chaque fois :

// 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 — le fournisseur d’infrastructure-as-code par défaut (cdk ou terraform) utilisé par les générateurs qui émettent de l’infrastructure (par exemple ts#infra, ts#api, py#api). Les générateurs qui acceptent un flag --iac utilisent par défaut inherit, qui lit cette valeur.
• containers.engine — l’interface CLI de conteneur (docker ou finch) intégrée dans les commandes de build/push/login générées. Les builds d’image-asset CDK récupèrent également cela via la variable d’environnement CDK_DOCKER. Consultez le guide de bundling Docker pour plus de détails.
• packageManager.catalogs — indique si les générateurs enregistrent les versions des dépendances dans le catalogue du gestionnaire de packages et les référencent avec le protocole catalog: (voir Politique de version unique). Définissez-le sur false pour que les générateurs écrivent directement les plages de versions dans le package.json de chaque projet. Cela n’a aucun effet sur npm, qui n’a pas de catalogue.

Le générateur de licence ajoute une clé license à ce même fichier pour configurer son propre comportement.

Vous pouvez modifier n’importe quel paramètre à tout moment — les exécutions ultérieures du générateur récupéreront la nouvelle valeur.