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 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

Options

Paramètre	Type	Par défaut	Description
addTsPlugin	boolean	true	Indique s'il faut ajouter le plugin ts.
iacProvider	string	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.
containerEngine	string	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 des deux n'est installé).

Structure de l’espace de travail

Répertoirepackages/ Vos projets se trouvent ici
- …
package.json package.json racine pour votre monorepo
nx.json Configuration Nx (cibles communes, générateurs de synchronisation, mise en cache)
tsconfig.base.json Configuration TypeScript racine
aws-nx-plugin.config.mts Configuration Nx Plugin for AWS
Répertoire.git-secrets/ Script bash git-secrets intégré pour l’analyse des identifiants
- …
Répertoire.husky/ Hooks Git
- …

Nx

Nx est un système de build agnostique au 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 plus 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 ou entre les 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 :

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

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 nx reset

yarn nx reset

npx nx reset

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 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 de non-concordance de version.

Du point de vue de Node, cela signifie un seul fichier de verrouillage à la racine avec un seul node_modules contenant toutes les dépendances. Si vous devez ajouter une nouvelle dépendance, ajoutez-la dans le package.json racine.

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 de l’espace de travail :

pnpm build

yarn build

npm run build

bun build

Lint

Linter et corriger automatiquement tous les projets :

pnpm lint

yarn lint

npm run lint

bun lint

Test

Exécuter les tests sur tous les projets :

pnpm test

yarn test

npm run test

bun test

Dev

Si vous avez un site web, démarrez-le ainsi que tous les composants connectés localement :

pnpm dev

yarn dev

npm run dev

bun dev

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 nx sync

yarn nx sync

npx nx sync

bunx nx sync

Exécuter des targets spécifiques

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

pnpm nx <target> <project>

yarn nx <target> <project>

npx nx <target> <project>

bunx nx <target> <project>

Par exemple :

pnpm nx build website

yarn nx build website

npx nx build website

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 ESLint pour l’analyse statique et Prettier pour le formatage du code. L’exécution de lint applique les deux à tous les projets.

Git Secrets

Les nouveaux espaces de travail incluent des hooks pre-commit git-secrets qui analysent les fichiers indexés à la recherche de modèles d’identifiants AWS avant chaque commit. Cela empêche la validation accidentelle de clés d’accès, de 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 :

# Autoriser un modèle regex spécifique
git secrets --add --allowed 'my-regex-pattern'

# Autoriser une chaîne littérale (les caractères spéciaux sont échappés)
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é avec votre équipe via le contrôle de version) :

# 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 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#trpc-api, py#fast-api). Les générateurs qui acceptent un flag --iacProvider utilisent par défaut Inherit, qui lit cette valeur.
containers.engine — le CLI de conteneur (docker ou finch) intégré dans les commandes de build/push/login générées. Les builds d’image-asset CDK récupèrent également cette valeur 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.