@aws/nx-plugin-mcp 1.0.0-rc.62 → 1.0.0-rc.64

package/bin/aws-nx-mcp.js

@@ -20849,6 +20849,7 @@ const NX_VERSION = {
 	"class-variance-authority": "0.7.1",
 	clsx: "2.1.1",
 	commander: "15.0.0",
+	"cpy-cli": "7.0.0",
 	electrodb: "3.9.1",
 	esbuild: "0.28.1",
 	"event-source-polyfill": "1.0.31",
@@ -20866,6 +20867,7 @@ const NX_VERSION = {
 	"@types/fs-extra": "11.0.4",
 	"make-dir-cli": "4.0.0",
 	mariadb: "3.5.3",
+	mise: "2026.8.3",
 	ncp: "2.0.0",
 	npm: "12.0.2",
 	"npm-check-updates": "22.2.9",
@@ -20878,7 +20880,6 @@ const NX_VERSION = {
 	rimraf: "6.1.3",
 	rolldown: "1.2.2",
 	"rolldown-plugin-dts": "0.28.0",
-	"@rollup/plugin-esm-shim": "0.1.8",
 	"simple-git": "3.36.0",
 	"source-map-support": "0.5.21",
 	"starlight-blog": "0.28.0",
@@ -53898,6 +53899,7 @@ ${PACKAGE_MANAGERS.map((pm) => buildNxCommand("<options>", pm)).join(" - \n")}
 - Generate all projects into the \`packages/\` directory
 - After making changes to your projects, fix linting issues, then run a full build
 - When it's time to start testing a project, suggest to the user that infrastructure is deployed to AWS. For websites, if a runtime-config.json is needed, use the load-runtime-config target after a deployment to point a local website at a sandbox stack.
+- For CDK infrastructure projects, deploy the sandbox stage with the \`deploy-sandbox\` target (eg \`nx deploy-sandbox infra\`) rather than passing a stage pattern to \`deploy\` — it already targets the sandbox stage declared in \`main.ts\`.
 
 ## Batching Generators
 

package/docs/get_started/quick-start.mdx

@@ -66,25 +66,25 @@ Otherwise, follow the steps below to run each generator yourself.
 
 ### Add a tRPC API
 
-<RunGenerator generator="ts#api" requiredParameters={{ name: 'demo-api', framework: 'trpc', auth: 'iam' }} />
+<RunGenerator generator="ts#api" requiredParameters={{ name: 'demo-api', framework: 'trpc', auth: 'iam' }} noInteractive />
 
 This will create the API inside the `packages/demo-api` folder.
 
 ### Add a React Website
 
-<RunGenerator generator="ts#website" requiredParameters={{ name: 'demo-website' }} />
+<RunGenerator generator="ts#website" requiredParameters={{ name: 'demo-website' }} noInteractive />
 
 This scaffolds a new React website in `packages/demo-website`.
 
 ### Add Cognito Authentication
 
-<RunGenerator generator="ts#website#auth" requiredParameters={{ project: '@my-project/demo-website', cognitoDomain: 'my-demo' }} />
+<RunGenerator generator="ts#website#auth" requiredParameters={{ project: '@my-project/demo-website', cognitoDomain: 'my-demo' }} noInteractive />
 
 This sets up the necessary infrastructure and React code to add Cognito Authentication to your website.
 
 ### Connect Frontend to Backend
 
-<RunGenerator generator="connection" requiredParameters={{ sourceProject: '@my-project/demo-website', targetProject: '@my-project/demo-api' }} />
+<RunGenerator generator="connection" requiredParameters={{ sourceProject: '@my-project/demo-website', targetProject: '@my-project/demo-api' }} noInteractive />
 
 This configures the necessary providers to ensure your website can call your tRPC API.
 
@@ -94,12 +94,12 @@ Add the infrastructure project based on your chosen IAC provider.
 
 <Infrastructure>
 <Fragment slot="cdk">
-<RunGenerator generator="ts#infra" requiredParameters={{ name: 'infra' }} />
+<RunGenerator generator="ts#infra" requiredParameters={{ name: 'infra' }} noInteractive />
 
 This configures a CDK App which you can use to deploy your infrastructure on AWS.
 </Fragment>
 <Fragment slot="terraform">
-<RunGenerator generator="terraform#project" requiredParameters={{ name: 'infra' }} />
+<RunGenerator generator="terraform#project" requiredParameters={{ name: 'infra' }} noInteractive />
 
 This configures a Terraform project which you can use to deploy your infrastructure on AWS.
 </Fragment>
@@ -247,7 +247,7 @@ Deploy your project:
 
 <Infrastructure>
 <Fragment slot="cdk">
-<NxCommands commands={['deploy infra "my-project-sandbox/*"']} />
+<NxCommands commands={['deploy-sandbox infra']} />
 </Fragment>
 <Fragment slot="terraform">
 <NxCommands commands={['apply infra']} />

package/docs/get_started/tutorials/dungeon-game/4.mdx

@@ -107,7 +107,7 @@ Your game is complete and you've tested every piece locally. Now let's deploy it
 
 ### Deploy your application
 
-<NxCommands commands={['deploy infra "dungeon-adventure-infra-sandbox/*"']} />
+<NxCommands commands={['deploy-sandbox infra']} />
 
 :::caution[Bootstrap Required]
 If this is the first CDK deployment in your AWS account/region, bootstrap it first:
@@ -115,6 +115,8 @@ If this is the first CDK deployment in your AWS account/region, bootstrap it fir
 <NxCommands commands={['bootstrap infra']} />
 :::
 
+The `deploy-sandbox` target deploys the sandbox stage defined in `packages/infra/src/main.ts`.
+
 Your first deployment will take around 6 minutes to complete as it waits for all resources to fully stabilize. Subsequent deployments are faster. To speed up iteration during development you can opt into [CloudFormation express mode](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cloudformation-express-mode.html) by passing the `--express` flag, which completes each resource operation as soon as its configuration is applied rather than waiting for full stabilization.
 
 Once the deployment completes, you will see outputs similar to the following:

package/docs/guides/smithy-project.mdx

@@ -43,7 +43,6 @@ If you want an API with an implementation, use the <Link path="guides/ts-smithy-
     - src
       - main.smithy Your shared shape definitions
     - smithy-build.json Smithy build configuration
-    - build.Dockerfile Builds and validates the model
     - project.json Project configuration and build targets
 
 </FileTree>
@@ -64,7 +63,7 @@ structure Customer {
 }
 ```
 
-Since a shape library has no service, its `smithy-build.json` configures no code generation — building it validates the model and assembles it into a single JSON model file at `dist/<my-shapes>/build/model/model.json`.
+Since a shape library has no service, its `smithy-build.json` configures no code generation — building it validates the model and assembles it into a single JSON model file at `dist/<my-shapes>/build/model.json`.
 
 </OptionFilter>
 
@@ -80,7 +79,7 @@ Since a shape library has no service, its `smithy-build.json` configures no code
       - operations
         - echo.smithy An example operation
     - smithy-build.json Smithy build configuration, including code generation
-    - build.Dockerfile Builds the model, OpenAPI spec and TypeScript Server SDK
+    - ssdk.rolldown.config.mjs Bundles the generated TypeScript Server SDK
     - project.json Project configuration and build targets
 
 </FileTree>
@@ -110,39 +109,32 @@ Building a service project generates an OpenAPI specification and a TypeScript S
 
 ## Building
 
-Smithy projects build using [Docker](https://www.docker.com/), which runs the [Smithy CLI](https://smithy.io/2.0/guides/smithy-cli/index.html) to validate your model:
+Smithy projects build with the [Smithy CLI](https://smithy.io/2.0/guides/smithy-cli/index.html), which validates your model:
 
 <NxCommands commands={['build my-shapes']} />
 
+On macOS and Linux the CLI is resolved by [mise](https://mise.jdx.dev/), which the build fetches on demand, so there is nothing to install — it downloads and caches the pinned version the first time you build. On Windows it is a prerequisite you install yourself — see <Link path="guides/ts-smithy-api#building-on-windows">Building on Windows</Link>.
+
 ## Depending on a Shape Library
 
-Building a shape library writes an assembled model to `dist/<my-shapes>/build/model/model.json`. This single file contains every shape the library defines, along with any it depends on, so a consumer only ever declares the libraries it references directly.
+Building a shape library writes an assembled model to `dist/<my-shapes>/build/model.json`. This single file contains every shape the library defines, along with any it depends on, so a consumer only ever declares the libraries it references directly.
 
-To depend on a shape library from another Smithy project, make three changes to the consuming project:
+To depend on a shape library from another Smithy project, make two changes to the consuming project:
 
 <Steps>
 
-1. Smithy projects build inside a container, and the build is given the workspace root as a named build context. Add a `COPY` to the consuming project's `build.Dockerfile`, alongside where its own sources are copied in:
-
-   ```dockerfile ins={4}
-   # Copy project files
-   COPY smithy-build.json .
-   COPY src src
-   COPY --from=workspace dist/packages/my-shapes/build/model/model.json deps/my-shapes.json
-   ```
-
-2. Add the copied file to `imports` in the consuming project's `smithy-build.json`:
+1. Add the library's built model to `imports` in the consuming project's `smithy-build.json`. Paths are relative to that file, so the number of `../` segments matches how deeply the consuming project is nested — three for `packages/my-api/model` below:
 
    ```json ins={4}
    {
      "version": "1.0",
      "sources": ["src/"],
-     "imports": ["deps/my-shapes.json"],
+     "imports": ["../../../dist/packages/my-shapes/build/model.json"],
      ...
    }
    ```
 
-3. Add the library's `build` target as a dependency of the consuming project's `compile` target in its `project.json`, so the model exists before the consumer builds:
+2. Add the library's `build` target as a dependency of the consuming project's `compile` target in its `project.json`, so the model exists before the consumer builds:
 
    ```json ins={4}
    {

package/docs/guides/ts-smithy-api.mdx

@@ -49,7 +49,7 @@ The generator creates two related projects in the `<directory>/<api-name>` direc
   - package.json Project manifest defining the project's package name and dependencies
   - project.json Project configuration and build targets
   - smithy-build.json Smithy build configuration
-  - build.Dockerfile Docker configuration for building Smithy artifacts
+  - ssdk.rolldown.config.mjs Bundles the generated TypeScript Server SDK
   - src/
     - main.smithy Main service definition
     - operations/
@@ -576,10 +576,12 @@ export const Echo: EchoOperation<ServiceContext> = async (input, ctx) => {
 
 ## Building and Code Generation
 
-The Smithy model project uses [Docker](https://www.docker.com/) to build the Smithy artifacts and generate the TypeScript Server SDK:
+The Smithy model project uses the [Smithy CLI](https://smithy.io/2.0/guides/smithy-cli/index.html) to build the Smithy artifacts and generate the TypeScript Server SDK:
 
 <NxCommands commands={['build <model-project>']} />
 
+On macOS and Linux the CLI is resolved by [mise](https://mise.jdx.dev/), which the build fetches on demand, so there is nothing to install — it downloads and caches the pinned version the first time you build.
+
 This process:
 
 1. **Compiles the Smithy model** and validates it
@@ -591,6 +593,39 @@ The backend project automatically copies the generated SDK during compilation:
 
 <NxCommands commands={['copy-ssdk <backend-project>']} />
 
+### Building on Windows
+
+`mise` publishes no Windows package to npm, so on Windows the Smithy CLI is a prerequisite you install yourself. Install it once following the [Smithy CLI installation guide](https://smithy.io/2.0/guides/smithy-cli/cli_installation.html) (for example `winget install smithy` or `scoop install smithy`), and make sure `smithy` is on your `PATH`. A Smithy project generated on Windows runs `smithy` directly rather than through `mise`.
+
+:::caution[Upgrading the CLI]
+Because the CLI is installed globally rather than pinned in your workspace, upgrading the workspace with `nx migrate` does **not** upgrade it. When a migration moves the Smithy dependencies forward, upgrade your global Smithy CLI to a matching version yourself.
+:::
+
+Alternatively, develop inside [WSL](https://learn.microsoft.com/en-us/windows/wsl/install), where the build runs the Linux path and `mise` resolves the CLI for you — nothing to install.
+
+A project generated on Windows commits a `compile` target that invokes `smithy` directly, so anyone else working on it — including on macOS or Linux — needs the Smithy CLI on their `PATH` too. To have those machines resolve the CLI through `mise` instead, switch the target to the `mise` command as [described below](#choosing-how-the-cli-is-resolved).
+
+### Choosing how the CLI is resolved
+
+macOS and Linux resolve the CLI through `mise` and Windows uses a globally installed CLI, but you can pick either on any platform by editing the `compile` target's command in the model project's `project.json`.
+
+To use a globally installed Smithy CLI instead of `mise`, replace the `mise` prefix with a bare `smithy`:
+
+```json title="project.json" del={5} ins={6}
+{
+  "targets": {
+    "compile": {
+      "options": {
+        "commands": ["... npx -y mise@<version> exec smithy@<version> -- smithy build ..."]
+        "commands": ["... smithy build ..."]
+      }
+    }
+  }
+}
+```
+
+To go back to `mise` resolving the CLI, restore the `npx -y mise@<version> exec smithy@<version> --` prefix.
+
 ### Bundle Target
 
 <Snippet name="ts-bundle" />

package/docs/guides/typescript-infrastructure.mdx

@@ -96,10 +96,14 @@ new ApplicationStage(app, 'my-app-sandbox', {
     region: process.env.CDK_DEFAULT_REGION,
   },
 });
+
+// Define other instances of stages, such as beta and prod, below
 ```
 
 The `env` property tells CDK which AWS account and region to deploy to. `CDK_DEFAULT_ACCOUNT` and `CDK_DEFAULT_REGION` are resolved automatically by the CDK CLI from your active AWS credentials. See the [CDK environments documentation](https://docs.aws.amazon.com/cdk/v2/guide/environments.html) for more details.
 
+The sandbox stage is the one the <Link path="guides/typescript-infrastructure#deploying-your-sandbox-stage">`deploy-sandbox` target</Link> deploys.
+
 If you generated with `stageConfig`, the `main.ts` reads account and region from a centralized config file instead, falling back to environment variables when no config is set:
 
 ```ts title="src/main.ts (with stageConfig)"
@@ -371,33 +375,41 @@ For more details, please refer to the [CDK bootstrapping documentation](https://
 
 ## Deploying to AWS
 
-After a build, you can deploy your infrastructure to AWS using the `deploy` target.
+Your project has three deploy targets, each suited to a different situation:
 
-:::caution[CI Deployment]
-Use the `deploy-ci` target if deploying in a CI/CD pipeline. See below for more details.
-:::
+| Target           | Use it for                                                                       |
+| ---------------- | -------------------------------------------------------------------------------- |
+| `deploy-sandbox` | Deploying your own sandbox stage during development. No stage argument needed.    |
+| `deploy`         | Deploying any stage, by naming the stage or stacks you want.                      |
+| `deploy-ci`      | Deploying from a CI/CD pipeline, using a pre-synthesized cloud assembly.          |
 
 First, make sure you have AWS credentials configured. If you generated with `stageConfig` and have configured stage credentials in `packages/common/infra-config/src/stages.config.ts`, the deploy command will automatically resolve and apply the correct credentials for the target stage. Otherwise, ensure your AWS credentials are set in your environment (e.g., via `AWS_PROFILE` or environment variables). See the [AWS credentials documentation](https://docs.aws.amazon.com/sdkref/latest/guide/access.html) for the available options.
 
-Then run the deploy target:
+### Deploying your Sandbox Stage
 
-<NxCommands commands={['deploy <my-infra> <my-infra>-sandbox/*']} />
+The `deploy-sandbox` target deploys the sandbox stage that `main.ts` declares, so you don't need to remember its stage name:
+
+<NxCommands commands={['deploy-sandbox <my-infra>']} />
+
+This is the quickest way to get your own copy of the application running in AWS while you develop.
 
 :::tip[Express Mode for Faster Deployments]
-The `deploy` target waits for full resource stabilization by default, favouring consistency over speed. To speed up iteration during development, opt into [CloudFormation express mode](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cloudformation-express-mode.html) by passing CDK's `--express` flag:
+The deploy targets wait for full resource stabilization by default, favouring consistency over speed. To speed up iteration during development, opt into [CloudFormation express mode](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cloudformation-express-mode.html) by passing CDK's `--express` flag:
 
-<NxCommands commands={['deploy <my-infra> <my-infra>-sandbox/* --express']} />
+<NxCommands commands={['deploy-sandbox <my-infra> --express']} />
 
 Express mode finishes once resource configuration is confirmed applied rather than waiting for full stabilization, with propagation continuing in the background, for significantly faster iteration cycles. It is intended for development and iteration.
 :::
 
-:::tip[Selective Stack Deployment]
-The above command deploys _all_ stacks for the `<my-infra>-sandbox` stage. You can specify other stages so long as they are defined in `main.ts`.
+### Deploying a Specific Stage
+
+The `deploy` target deploys whichever stage or stacks you name. Use it for stages other than your sandbox, or to deploy a single stack:
 
-You can also deploy individual stacks by specifying the full stack name, for example:
+<NxCommands commands={['deploy <my-infra> <my-infra>-sandbox/*']} />
+
+You can specify any stage so long as it is defined in `main.ts`. To deploy an individual stack, give the full stack name:
 
 <NxCommands commands={['deploy <my-infra> <my-infra>-sandbox/Application']} />
-:::
 
 ## Deploying to AWS in a CI/CD Pipeline
 

package/docs/snippets/prerequisites.mdx

@@ -10,13 +10,7 @@ import Snippet from '@components/snippet.astro';
 
 ### Recommended
 
-- [PNPM >= 11](https://pnpm.io/installation#using-npm) (you can also use [Yarn >= 4](https://yarnpkg.com/getting-started/install), [Bun >= 1](https://bun.sh/docs/installation), or [NPM >= 10](https://nodejs.org/en/learn/getting-started/an-introduction-to-the-npm-package-manager) if you prefer)
-  - verify by running `pnpm --version`, `yarn --version`, `bun --version` or `npm --version`
-- [AWS Credentials](https://docs.aws.amazon.com/sdkref/latest/guide/access.html) configured to your target AWS account are required to deploy your application (as well as for some local development workflows).
-- [Docker](https://www.docker.com/) or [Finch >= 1.6.0](https://runfinch.com/) is required for some generators. For Docker, [multi-platform builds](https://docs.docker.com/build/building/multi-platform/) must be set up; Finch supports [multi-platform builds](https://runfinch.com/docs/getting-started/building-images/#building-a-multi-architecture-container-image) out of the box.
-- [Terraform >= 1.12](https://developer.hashicorp.com/terraform/install) is required if you choose to use this for infrastructure as code instead of CDK
-  - verify by running `terraform --version`
-- If you are using [VSCode](https://code.visualstudio.com/), we recommend installing the [Nx Console VSCode Plugin](https://marketplace.visualstudio.com/items?itemName=nrwl.angular-console).
+<Snippet name="recommended-prerequisites" parentHeading="Recommended" />
 
 :::tip[AI Assistant Setup]
 If you use an AI Assistant such as Kiro, Kiro CLI, Cursor, Claude Code or Cline, you may also wish to <Link path="/get_started/building-with-ai">install the Nx Plugin for AWS MCP server.</Link>

package/docs/snippets/recommended-prerequisites.mdx

@@ -0,0 +1,10 @@
+---
+title: Recommended Prerequisites
+---
+- [PNPM >= 11](https://pnpm.io/installation#using-npm) (you can also use [Yarn >= 4](https://yarnpkg.com/getting-started/install), [Bun >= 1](https://bun.sh/docs/installation), or [NPM >= 10](https://nodejs.org/en/learn/getting-started/an-introduction-to-the-npm-package-manager) if you prefer)
+  - verify by running `pnpm --version`, `yarn --version`, `bun --version` or `npm --version`
+- [AWS Credentials](https://docs.aws.amazon.com/sdkref/latest/guide/access.html) configured to your target AWS account are required to deploy your application (as well as for some local development workflows).
+- [Docker](https://www.docker.com/) or [Finch >= 1.6.0](https://runfinch.com/) is required for some generators. For Docker, [multi-platform builds](https://docs.docker.com/build/building/multi-platform/) must be set up; Finch supports [multi-platform builds](https://runfinch.com/docs/getting-started/building-images/#building-a-multi-architecture-container-image) out of the box.
+- [Terraform >= 1.12](https://developer.hashicorp.com/terraform/install) is required if you choose to use this for infrastructure as code instead of CDK
+  - verify by running `terraform --version`
+- If you are using [VSCode](https://code.visualstudio.com/), we recommend installing the [Nx Console VSCode Plugin](https://marketplace.visualstudio.com/items?itemName=nrwl.angular-console).

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@aws/nx-plugin-mcp",
-  "version": "1.0.0-rc.62",
+  "version": "1.0.0-rc.64",
   "repository": {
     "type": "git",
     "url": "https://github.com/awslabs/nx-plugin-for-aws.git",