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

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

Options

Paramètre	Type	Par défaut	Description
iac	cdk | terraform	cdk	Le fournisseur IaC préféré.
gitSecrets	boolean	true	Indique s'il faut configurer git-secrets pour empêcher la validation de credentials AWS.
mcp	boolean	true	Indique s'il faut configurer le plugin Nx pour le serveur AWS MCP afin qu'il soit utilisé par les agents de codage.
containers	infer | docker | finch	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é).
module	esm | cjs	esm	Format de module pour le code TypeScript et la configuration générés.
catalog	boolean	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é.
preferInstallDependencies	boolean	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
• aws-nx-plugin.config.mts Nx Plugin for AWS configuration
• Répertoire.git-secrets/ Vendored git-secrets bash script for credential scanning

  • …
• 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 — en particulier en CI. 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.

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.

Git Secrets

Les nouveaux espaces de travail incluent 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.

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
git secrets --add --allowed 'my-regex-pattern'

# Allow a literal string (special characters are escaped)
git secrets --add --allowed --literal 'my-literal+string'

Vous pouvez également créer un fichier .gitallowed à la racine du dépôt avec une regex compatible egrep par ligne (partagée avec votre équipe via le contrôle de version) :

.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. Deux paramètres sont particulièrement utiles :

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

export default {
  iac: {
    provider: 'cdk', // or 'terraform'
  },
  containers: {
    engine: 'docker', // or 'finch'
  },
} 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.

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