@aws/nx-plugin-mcp 1.0.0-rc.48 → 1.0.0-rc.49
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/bin/aws-nx-mcp.js +19370 -19340
- package/docs/get_started/upgrading.mdx +147 -0
- package/docs/guides/nx-migration.mdx +163 -0
- package/generators.json +7 -0
- package/package.json +1 -1
- package/src/ts/nx-migration/schema.json +63 -0
|
@@ -0,0 +1,147 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: Upgrading Your Workspace
|
|
3
|
+
description: How to upgrade Nx and @aws/nx-plugin with nx migrate.
|
|
4
|
+
---
|
|
5
|
+
import { Aside } from '@astrojs/starlight/components';
|
|
6
|
+
import Link from '@components/link.astro';
|
|
7
|
+
import InstallCommand from '@components/install-command.astro';
|
|
8
|
+
import NxCommands from '@components/nx-commands.astro';
|
|
9
|
+
import PackageManagerShortCommand from '@components/package-manager-short-command.astro';
|
|
10
|
+
|
|
11
|
+
`@aws/nx-plugin` ships migrations that update your workspace automatically when you upgrade it, using [`nx migrate`](https://nx.dev/docs/features/automate-updating-dependencies).
|
|
12
|
+
|
|
13
|
+
<Aside type="tip">
|
|
14
|
+
You can use your agentic coding tool of choice to upgrade your workspace for you, using the <Link path="get_started/building-with-ai">MCP server</Link>. Try the prompt:
|
|
15
|
+
|
|
16
|
+
> Upgrade Nx and the Nx Plugin for AWS in this workspace.
|
|
17
|
+
</Aside>
|
|
18
|
+
|
|
19
|
+
## Upgrading @aws/nx-plugin
|
|
20
|
+
|
|
21
|
+
First, run the following command to update the plugin version and prepare migrations:
|
|
22
|
+
|
|
23
|
+
<NxCommands commands={['migrate @aws/nx-plugin@latest']} />
|
|
24
|
+
|
|
25
|
+
```
|
|
26
|
+
NX The migrate command has run successfully.
|
|
27
|
+
|
|
28
|
+
- package.json has been updated.
|
|
29
|
+
- migrations.json has been generated.
|
|
30
|
+
- 1 AI migration prompt(s) have been written to tools/ai-migrations/.
|
|
31
|
+
|
|
32
|
+
NX Next steps:
|
|
33
|
+
|
|
34
|
+
- Make sure package.json changes make sense and then run 'pnpm install --no-frozen-lockfile',
|
|
35
|
+
- Review and tweak the AI migration prompts in tools/ai-migrations/ as needed.
|
|
36
|
+
- Run 'pnpm exec nx migrate --run-migrations'
|
|
37
|
+
- To learn more go to https://nx.dev/features/automate-updating-dependencies
|
|
38
|
+
```
|
|
39
|
+
|
|
40
|
+
Review the `package.json` changes then install:
|
|
41
|
+
|
|
42
|
+
<InstallCommand />
|
|
43
|
+
|
|
44
|
+
Then run the migrations:
|
|
45
|
+
|
|
46
|
+
<NxCommands commands={['migrate --run-migrations']} />
|
|
47
|
+
|
|
48
|
+
### Deterministic migrations
|
|
49
|
+
|
|
50
|
+
Most migrations are deterministic codemods — they run unattended and report anything they deliberately skipped:
|
|
51
|
+
|
|
52
|
+
```
|
|
53
|
+
NX Running migrations from 'migrations.json'
|
|
54
|
+
|
|
55
|
+
Running the following migrations:
|
|
56
|
+
- @aws/nx-plugin: update-vitest-workspace-config — Add a coverage reporter to vitest configs
|
|
57
|
+
- @aws/nx-plugin: update-custom-api-handlers — Update custom API handlers for the new middleware signature
|
|
58
|
+
|
|
59
|
+
── Migration 1 of 2 · @aws/nx-plugin:update-vitest-workspace-config ─────
|
|
60
|
+
→ Running generator…
|
|
61
|
+
Changes:
|
|
62
|
+
UPDATE packages/api/vite.config.mts
|
|
63
|
+
|
|
64
|
+
...
|
|
65
|
+
|
|
66
|
+
NX Successfully finished running migrations from 'migrations.json'.
|
|
67
|
+
|
|
68
|
+
2 migrations applied, 0 commits created.
|
|
69
|
+
|
|
70
|
+
NX Some migrations have additional information, see below.
|
|
71
|
+
|
|
72
|
+
- packages/website/vite.config.mts has a customised shape; add a coverage reporter manually.
|
|
73
|
+
```
|
|
74
|
+
|
|
75
|
+
Pay attention to the **additional information** at the end: when a migration finds a file you have customised beyond what it can safely update, it leaves your changes alone and reports the manual follow-up there instead.
|
|
76
|
+
|
|
77
|
+
### Agentic migrations
|
|
78
|
+
|
|
79
|
+
Some migrations target code you own, where the right edit depends on what you've built — these ship as prompts applied by your local AI coding agent (Claude Code, Codex or OpenCode). When any are pending, Nx asks for consent before involving an agent:
|
|
80
|
+
|
|
81
|
+
```
|
|
82
|
+
? Enable the agentic flow? …
|
|
83
|
+
❯ Yes, just this time Apply 1 prompt migration and validate generator output with an AI agent
|
|
84
|
+
Yes, always Saved to nx.json so Nx won't ask again
|
|
85
|
+
No, just this time Skip prompts and run generators without AI validation
|
|
86
|
+
No, never Saved to nx.json so Nx won't ask again
|
|
87
|
+
```
|
|
88
|
+
|
|
89
|
+
If you accept, the agent applies each prompt migration in place and summarises what it changed:
|
|
90
|
+
|
|
91
|
+
```
|
|
92
|
+
── Migration 2 of 2 · @aws/nx-plugin:update-custom-api-handlers ─────────
|
|
93
|
+
→ Running prompt with Claude Code…
|
|
94
|
+
✓ update-custom-api-handlers: Updated 3 API handlers to the new middleware signature.
|
|
95
|
+
```
|
|
96
|
+
|
|
97
|
+
If you decline — or no agent is installed, or the run is non-interactive (e.g. CI) — the prompt migrations are skipped and saved for you to apply by hand:
|
|
98
|
+
|
|
99
|
+
```
|
|
100
|
+
── Migration 2 of 2 · @aws/nx-plugin:update-custom-api-handlers ─────────
|
|
101
|
+
↷ Skipped — agentic flow disabled. Listed in next steps.
|
|
102
|
+
|
|
103
|
+
NX Successfully finished running migrations from 'migrations.json'.
|
|
104
|
+
|
|
105
|
+
1 migration applied, 0 commits created, 1 prompt migration skipped.
|
|
106
|
+
|
|
107
|
+
NX Some migrations have additional information, see below.
|
|
108
|
+
|
|
109
|
+
- Some prompt migrations were skipped. Review and apply each of the following
|
|
110
|
+
prompt files to the workspace, in the listed order:
|
|
111
|
+
- tools/ai-migrations/@aws/nx-plugin/2.0.0/prompt.md
|
|
112
|
+
```
|
|
113
|
+
|
|
114
|
+
Each skipped prompt is a self-contained markdown instruction file in `tools/ai-migrations/` — paste it into your coding agent, or follow its steps manually.
|
|
115
|
+
|
|
116
|
+
Finally, verify everything still builds, then delete `migrations.json` and commit:
|
|
117
|
+
|
|
118
|
+
<PackageManagerShortCommand commands={['build']} />
|
|
119
|
+
|
|
120
|
+
## Upgrading with an AI agent
|
|
121
|
+
|
|
122
|
+
The whole flow can be driven by an AI coding agent end to end — nothing blocks on an interactive terminal. When `nx migrate --run-migrations` runs from inside an agent, Nx detects this, skips the agentic consent prompt, and instead of spawning a nested agent it **defers** each prompt migration back to the agent driving the run:
|
|
123
|
+
|
|
124
|
+
```
|
|
125
|
+
── Migration 2 of 2 · @aws/nx-plugin:update-custom-api-handlers ─────────
|
|
126
|
+
↷ Skipped — deferred to the AI agent driving this run. Listed in next steps.
|
|
127
|
+
|
|
128
|
+
NX Successfully finished running migrations from 'migrations.json'.
|
|
129
|
+
|
|
130
|
+
1 migration applied, 0 commits created, 1 prompt migration deferred.
|
|
131
|
+
|
|
132
|
+
NX Next steps for the AI agent driving this run
|
|
133
|
+
|
|
134
|
+
Apply the deferred prompts below, in order:
|
|
135
|
+
1. tools/ai-migrations/@aws/nx-plugin/2.0.0/prompt.md
|
|
136
|
+
(update-custom-api-handlers — prompt-only migration)
|
|
137
|
+
Then relay these migration-emitted notes to the user:
|
|
138
|
+
- packages/website/vite.config.mts has a customised shape; add a coverage reporter manually.
|
|
139
|
+
Finally, summarize what was done across the run and commit the changes per workspace conventions.
|
|
140
|
+
```
|
|
141
|
+
|
|
142
|
+
An agent conducting an upgrade should:
|
|
143
|
+
|
|
144
|
+
1. Run the cycle above for one package at a time (`nx migrate <package>@latest`, install, `nx migrate --run-migrations`), passing `--no-interactive` to suppress any remaining prompts.
|
|
145
|
+
2. After the run, read each deferred prompt file listed under **Next steps**, in the listed order, and apply its steps directly to the workspace.
|
|
146
|
+
3. Relay any migration-emitted notes (skipped customised files, manual follow-ups) to the user.
|
|
147
|
+
4. Verify the workspace builds, then delete `migrations.json` and commit before starting the next package's upgrade.
|
|
@@ -0,0 +1,163 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: Nx Migration Generator
|
|
3
|
+
description: Generates an Nx Migration for an Nx Plugin
|
|
4
|
+
generator: ts#nx-migration
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
import { FileTree } from '@astrojs/starlight/components';
|
|
8
|
+
import RunGenerator from '@components/run-generator.astro';
|
|
9
|
+
import NxCommands from '@components/nx-commands.astro';
|
|
10
|
+
import GeneratorParameters from '@components/generator-parameters.astro';
|
|
11
|
+
import Link from '@components/link.astro';
|
|
12
|
+
|
|
13
|
+
Adds an [Nx Migration](https://nx.dev/docs/kb/migration-generators) to an Nx Plugin. Migrations let `nx migrate` automatically update projects that were generated by a previous version of your plugin when you make a breaking change — renamed targets, changed vended config, or a dependency bump that requires accompanying code changes.
|
|
14
|
+
|
|
15
|
+
The generator scaffolds the migration, registers it in your plugin's `migrations.json`, and wires the `nx-migrations` field into your plugin's `package.json` (creating both if they don't exist yet).
|
|
16
|
+
|
|
17
|
+
:::tip[Recommended Setup]
|
|
18
|
+
We recommend using the <Link path="/guides/ts-nx-plugin">`ts#nx-plugin`</Link> generator as the base project for your migrations, since it configures a plugin project set up to publish generators and migrations.
|
|
19
|
+
:::
|
|
20
|
+
|
|
21
|
+
## Usage
|
|
22
|
+
|
|
23
|
+
### Generate a Migration
|
|
24
|
+
|
|
25
|
+
<RunGenerator generator="ts#nx-migration" />
|
|
26
|
+
|
|
27
|
+
### Options
|
|
28
|
+
|
|
29
|
+
<GeneratorParameters generator="ts#nx-migration" />
|
|
30
|
+
|
|
31
|
+
## The three kinds of migration
|
|
32
|
+
|
|
33
|
+
Migrations come in three forms, discriminated by which fields the `migrations.json` entry carries. Pass `--kind` to choose (default `deterministic`):
|
|
34
|
+
|
|
35
|
+
- **Deterministic** (`implementation`) — a codemod with an exact before/after. Runs unattended, including in CI and non-interactive terminals. Use it alone when the change has a shape you can match reliably everywhere it appears.
|
|
36
|
+
- **Agentic** (`prompt`) — a markdown instruction file applied by the user's local coding agent via Nx's agentic `nx migrate` flow. Use it alone when no mechanical before/after holds, because the correct edit depends on what the user has built. When no agent runs (CI, no agent installed, consent declined), Nx surfaces the prompt as manual instructions — so write prompts as self-contained, human-actionable steps.
|
|
37
|
+
- **Hybrid** (`implementation` + `prompt`) — both halves of one change, and usually the right choice. Everything your generators vend is code the user owns and may have modified, so the codemod does as much as it can safely match and returns `agentContext` describing what it changed *and what it skipped*; Nx passes that context to the paired `prompt`, which directs the agent at the rest.
|
|
38
|
+
|
|
39
|
+
## Generator Output
|
|
40
|
+
|
|
41
|
+
The generator creates the following files under your plugin project's source folder, depending on the chosen `kind`:
|
|
42
|
+
|
|
43
|
+
<FileTree>
|
|
44
|
+
- src/migrations/latest/\<name>/
|
|
45
|
+
- migration.ts Codemod implementation (deterministic and hybrid)
|
|
46
|
+
- migration.spec.ts Tests for your migration (deterministic and hybrid)
|
|
47
|
+
- prompt.md Agent/human instructions (agentic and hybrid)
|
|
48
|
+
- migrations.json Created or updated to register your migration
|
|
49
|
+
- package.json Created or updated to add an "nx-migrations" entry
|
|
50
|
+
</FileTree>
|
|
51
|
+
|
|
52
|
+
A new migration lands in `latest/`. Grouping migrations by the release that ships them keeps their order visible at a glance as the collection grows — move a migration into a `v<x.y.z>/` folder (and update its paths in `migrations.json`) when you assign its version.
|
|
53
|
+
|
|
54
|
+
It registers the migration in `migrations.json` with the fields for its kind and no `version` — see [Versioning](#versioning) below. The registered key is prefixed with the folder the migration lives in (`latest-<name>`), so reusing a name for a later change can't silently overwrite a migration that has already shipped.
|
|
55
|
+
|
|
56
|
+
## Implementing a Migration
|
|
57
|
+
|
|
58
|
+
A deterministic (or hybrid) migration is a function which mutates the virtual filesystem (the `Tree`), returning a [`MigrationReturnObject`](https://nx.dev/docs/reference/devkit/MigrationReturnObject). Here's a hybrid one, which returns both:
|
|
59
|
+
|
|
60
|
+
```ts
|
|
61
|
+
import { type MigrationReturnObject, type Tree } from '@nx/devkit';
|
|
62
|
+
import { formatFilesInSubtree } from '@aws/nx-plugin/sdk/utils/format';
|
|
63
|
+
|
|
64
|
+
export default async function migration(
|
|
65
|
+
tree: Tree,
|
|
66
|
+
): Promise<MigrationReturnObject> {
|
|
67
|
+
const nextSteps: string[] = [];
|
|
68
|
+
const agentContext: string[] = [];
|
|
69
|
+
|
|
70
|
+
// Read and update the files your generators produce here.
|
|
71
|
+
|
|
72
|
+
await formatFilesInSubtree(tree);
|
|
73
|
+
|
|
74
|
+
return { nextSteps, agentContext };
|
|
75
|
+
}
|
|
76
|
+
```
|
|
77
|
+
|
|
78
|
+
- **`nextSteps`** — workspace-wide notes surfaced to the user after `nx migrate` runs. Use these to report files you skipped (see the guardrails below) or manual follow-up the migration couldn't perform.
|
|
79
|
+
- **`agentContext`** (hybrid only) — a summary of what the codemod changed, passed to the paired `prompt` when it runs under Nx's agentic flow so the agent can focus on the user-owned parts.
|
|
80
|
+
|
|
81
|
+
For some example operations you can perform in your migration (generating files, modifying existing files using GritQL, reading and updating JSON), refer to the <Link path="/guides/nx-generator">Nx Generator guide</Link>.
|
|
82
|
+
|
|
83
|
+
### Guardrails
|
|
84
|
+
|
|
85
|
+
Migrations run against workspaces you don't control, so it is recommended to adhere to the following (the scaffolded skeleton bakes these in):
|
|
86
|
+
|
|
87
|
+
- **Pattern-match before writing.** If a target file has diverged from the shape your generators produce, skip it and report it via `nextSteps`, or consider a hybrid migration, rather than clobbering the user's changes.
|
|
88
|
+
- **Idempotent.** Re-running the migration must be a no-op.
|
|
89
|
+
- **Format what you write.** Finish with `formatFilesInSubtree(tree)` so the files your migration wrote are formatted correctly.
|
|
90
|
+
|
|
91
|
+
### Testing Your Migration
|
|
92
|
+
|
|
93
|
+
The scaffolded `migration.spec.ts` uses `createTreeUsingTsSolutionSetup()` to build a virtual workspace matching the shape our preset generates. Test that the migration takes a workspace from the "before" state to the target state, skips (and reports) code it doesn't recognise, and is idempotent:
|
|
94
|
+
|
|
95
|
+
```ts
|
|
96
|
+
import type { Tree } from '@nx/devkit';
|
|
97
|
+
import { createTreeUsingTsSolutionSetup } from '@aws/nx-plugin/sdk/utils/test';
|
|
98
|
+
import migration from './migration';
|
|
99
|
+
|
|
100
|
+
describe('my migration', () => {
|
|
101
|
+
let tree: Tree;
|
|
102
|
+
|
|
103
|
+
beforeEach(() => {
|
|
104
|
+
tree = createTreeUsingTsSolutionSetup();
|
|
105
|
+
});
|
|
106
|
+
|
|
107
|
+
it('should update the generated shape', async () => {
|
|
108
|
+
// Set up a tree with the "before" state
|
|
109
|
+
tree.write('project.json', JSON.stringify({ targets: { foo: {} } }));
|
|
110
|
+
|
|
111
|
+
// Run the migration
|
|
112
|
+
await migration(tree);
|
|
113
|
+
|
|
114
|
+
// Check that the tree matches the target state
|
|
115
|
+
const projectJson = JSON.parse(tree.read('project.json', 'utf-8'));
|
|
116
|
+
expect(projectJson.targets).toHaveProperty('bar');
|
|
117
|
+
expect(projectJson.targets).not.toHaveProperty('foo');
|
|
118
|
+
});
|
|
119
|
+
});
|
|
120
|
+
```
|
|
121
|
+
|
|
122
|
+
Unit tests only prove the migration does what you wrote it to do. Also test it against a workspace generated by the **published** version of your plugin — the state your users upgrade from — and confirm the result matches what your generators produce today: inspect the diff, generate the same projects into a fresh workspace and compare, check the workspace still builds, then re-run the migration to confirm it changes nothing. Repeat with a workspace you've customised first, to check the migration leaves your edits alone and reports them instead.
|
|
123
|
+
|
|
124
|
+
## Versioning
|
|
125
|
+
|
|
126
|
+
Nx runs a migration when the user's installed plugin version is less than the migration's `version`. This generator writes **no** `version` field — assign it (or stamp it from your release process) when you cut the release that ships the migration, so it runs for everyone upgrading from an earlier version.
|
|
127
|
+
|
|
128
|
+
Once you assign versions, a `migrations.json` registering one migration of each kind looks like this:
|
|
129
|
+
|
|
130
|
+
```json
|
|
131
|
+
{
|
|
132
|
+
"$schema": "http://json-schema.org/schema",
|
|
133
|
+
"name": "my-plugin",
|
|
134
|
+
"generators": {
|
|
135
|
+
"v2.0.0-rename-foo-target": {
|
|
136
|
+
"version": "2.0.0",
|
|
137
|
+
"description": "Rename the foo target to bar",
|
|
138
|
+
"implementation": "./src/migrations/v2.0.0/rename-foo-target/migration"
|
|
139
|
+
},
|
|
140
|
+
"v3.0.0-migrate-custom-handlers": {
|
|
141
|
+
"version": "3.0.0",
|
|
142
|
+
"description": "Update custom handlers for the new API",
|
|
143
|
+
"prompt": "./src/migrations/v3.0.0/migrate-custom-handlers/prompt.md"
|
|
144
|
+
},
|
|
145
|
+
"v4.0.0-upgrade-framework": {
|
|
146
|
+
"version": "4.0.0",
|
|
147
|
+
"description": "Upgrade the framework and reconcile call sites",
|
|
148
|
+
"implementation": "./src/migrations/v4.0.0/upgrade-framework/migration",
|
|
149
|
+
"prompt": "./src/migrations/v4.0.0/upgrade-framework/prompt.md"
|
|
150
|
+
}
|
|
151
|
+
}
|
|
152
|
+
}
|
|
153
|
+
```
|
|
154
|
+
|
|
155
|
+
## Running Migrations
|
|
156
|
+
|
|
157
|
+
Users apply your plugin's migrations with the two-step `nx migrate` flow — generate the pending migrations, install, then run them:
|
|
158
|
+
|
|
159
|
+
<NxCommands commands={['migrate my-plugin@latest', 'migrate --run-migrations']} />
|
|
160
|
+
|
|
161
|
+
Agentic and hybrid migrations are applied by the user's local coding agent during `nx migrate --run-migrations` when one is available.
|
|
162
|
+
|
|
163
|
+
For the full flow from the upgrading user's perspective — including example output for deterministic and agentic migrations — see <Link path="get_started/upgrading">Upgrading Your Workspace</Link>.
|
package/generators.json
CHANGED
|
@@ -231,6 +231,13 @@
|
|
|
231
231
|
"metric": "g17",
|
|
232
232
|
"guidePages": ["nx-generator"]
|
|
233
233
|
},
|
|
234
|
+
"ts#nx-migration": {
|
|
235
|
+
"factory": "./src/ts/nx-migration/generator",
|
|
236
|
+
"schema": "./src/ts/nx-migration/schema.json",
|
|
237
|
+
"description": "Generator for adding an Nx Migration to an Nx Plugin, applied by nx migrate when users upgrade",
|
|
238
|
+
"metric": "g68",
|
|
239
|
+
"guidePages": ["nx-migration"]
|
|
240
|
+
},
|
|
234
241
|
"ts#nx-plugin": {
|
|
235
242
|
"factory": "./src/ts/nx-plugin/generator",
|
|
236
243
|
"schema": "./src/ts/nx-plugin/schema.json",
|
package/package.json
CHANGED
|
@@ -0,0 +1,63 @@
|
|
|
1
|
+
{
|
|
2
|
+
"$schema": "https://json-schema.org/schema",
|
|
3
|
+
"$id": "TsNxMigration",
|
|
4
|
+
"title": "Create an Nx Migration",
|
|
5
|
+
"description": "Scaffold a migration for an Nx Plugin, applied by nx migrate when users upgrade",
|
|
6
|
+
"type": "object",
|
|
7
|
+
"properties": {
|
|
8
|
+
"project": {
|
|
9
|
+
"type": "string",
|
|
10
|
+
"description": "The Nx Plugin project to add the migration to. We recommend using the ts#nx-plugin generator to create this.",
|
|
11
|
+
"x-priority": "important",
|
|
12
|
+
"x-prompt": "Choose the Nx Plugin project to add the migration to",
|
|
13
|
+
"x-dropdown": "projects",
|
|
14
|
+
"$default": {
|
|
15
|
+
"$source": "argv",
|
|
16
|
+
"index": 0
|
|
17
|
+
}
|
|
18
|
+
},
|
|
19
|
+
"name": {
|
|
20
|
+
"type": "string",
|
|
21
|
+
"description": "Migration name, in kebab-case (e.g. rename-foo-target)",
|
|
22
|
+
"x-priority": "important",
|
|
23
|
+
"x-prompt": "What is the name of the migration? (kebab-case, e.g. rename-foo-target)"
|
|
24
|
+
},
|
|
25
|
+
"description": {
|
|
26
|
+
"type": "string",
|
|
27
|
+
"description": "A description of what the migration does, shown by nx migrate",
|
|
28
|
+
"x-priority": "important",
|
|
29
|
+
"x-prompt": "Describe what the migration does"
|
|
30
|
+
},
|
|
31
|
+
"kind": {
|
|
32
|
+
"type": "string",
|
|
33
|
+
"description": "The kind of migration: deterministic (a codemod), agentic (an AI-applied prompt for user-owned code), or hybrid (a codemod that does the mechanical part then hands off to an agent)",
|
|
34
|
+
"enum": ["deterministic", "agentic", "hybrid"],
|
|
35
|
+
"default": "deterministic",
|
|
36
|
+
"x-priority": "important",
|
|
37
|
+
"x-prompt": {
|
|
38
|
+
"message": "What kind of migration is this?",
|
|
39
|
+
"type": "list",
|
|
40
|
+
"items": [
|
|
41
|
+
{
|
|
42
|
+
"value": "deterministic",
|
|
43
|
+
"label": "Deterministic — a codemod with an exact before/after (runs unattended, incl. CI)"
|
|
44
|
+
},
|
|
45
|
+
{
|
|
46
|
+
"value": "agentic",
|
|
47
|
+
"label": "Agentic — an AI-applied prompt for changes to user-owned code"
|
|
48
|
+
},
|
|
49
|
+
{
|
|
50
|
+
"value": "hybrid",
|
|
51
|
+
"label": "Hybrid — a codemod for the mechanical part that hands off to an agent for the rest"
|
|
52
|
+
}
|
|
53
|
+
]
|
|
54
|
+
}
|
|
55
|
+
},
|
|
56
|
+
"preferInstallDependencies": {
|
|
57
|
+
"type": "boolean",
|
|
58
|
+
"description": "Whether to prefer installing dependencies after the generator runs. Set to false to defer installing when batching multiple generators (an install still runs if needed so subsequent generators can compute the Nx project graph); install once at the end.",
|
|
59
|
+
"default": true
|
|
60
|
+
}
|
|
61
|
+
},
|
|
62
|
+
"required": ["project", "name"]
|
|
63
|
+
}
|