@aws/nx-plugin-mcp 1.0.0-rc.63 → 1.0.0-rc.65

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

package/docs/guides/docker-bundling.mdx

@@ -109,7 +109,7 @@ export default defineConfig([
     output: {
       file: '../../dist/packages/my-project/bundle/index.js',
       format: 'cjs',
-      inlineDynamicImports: true,
+      codeSplitting: false,
     },
     platform: 'node',
   },

package/docs/guides/nx-generator.mdx

@@ -497,7 +497,7 @@ Unit tests for generators are straightforward to implement. Here's a typical pat
 
 ```typescript
 import { createTreeWithEmptyWorkspace } from '@nx/devkit/testing';
-import { yourGenerator } from './generator';
+import { yourGenerator } from './generator.js';
 
 describe('your generator', () => {
   let tree;

package/docs/guides/nx-migration.mdx

@@ -97,7 +97,7 @@ The scaffolded `migration.spec.ts` uses `createTreeUsingTsSolutionSetup()` to bu
 ```ts
 import type { Tree } from '@nx/devkit';
 import { createTreeUsingTsSolutionSetup } from '@aws/nx-plugin/sdk/utils/test';
-import migration from './migration';
+import migration from './migration.js';
 
 describe('my migration', () => {
   let tree: Tree;

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-project.mdx

@@ -292,7 +292,7 @@ export default defineConfig([
     output: {
       file: '../../dist/packages/my-library/bundle/index.js',
       format: 'cjs',
-      inlineDynamicImports: true,
+      codeSplitting: false,
     },
   },
 ]);

package/package.json

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