@go-to-k/cdkd 0.275.1 → 0.275.2

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/README.md CHANGED
@@ -7,18 +7,54 @@
7
7
  Drop-in CDK CLI for existing CDK apps — up to 15x faster deploys via direct AWS SDK calls instead of CloudFormation.
8
8
 
9
9
  - **Drop-in CDK compatible**: your existing CDK app code runs as-is; just replace `cdk deploy` with `cdkd deploy`.
10
- - **Up to 15x faster deploys**: direct SDK calls, aggressive parallelization, and `--no-wait` to skip slow stabilization waits.
11
- - **Faster than Terraform and CloudFormation Express mode**: wins or ties every benchmarked scenario against Terraform, and beats CloudFormation's own fast-deploy option on nearly every stack, by up to 9x (see [Benchmark](#benchmark)).
10
+ - **Up to 15x faster deploys**: direct SDK calls, aggressive parallelization, and `--no-wait` to skip slow stabilization waits; **faster than Terraform and CloudFormation Express mode** too (see [Benchmark](#benchmark)).
12
11
 
13
12
  ![cdk deploy vs cdkd deploy — side-by-side, 35s recording, real AWS deploy. cdkd finishes while cdk is still creating its CloudFormation changeset.](assets/cdk-vs-cdkd.gif)
14
13
 
15
- **cdkd complements the AWS CDK CLI rather than replacing it.** Use cdkd in dev/test for rapid iteration and local execution; use the AWS CDK CLI in production for full CloudFormation tooling. Install cdkd alongside an existing `cdk deploy` workflow: no migration needed. Bidirectional migration is also supported: [import](#importing-existing-resources) into cdkd or [export](#exporting-a-stack-back-to-cloudformation) back to CloudFormation when ready.
14
+ **cdkd complements the AWS CDK CLI rather than replacing it.** Use cdkd in dev/test for rapid iteration; use the AWS CDK CLI in production for full CloudFormation tooling. Install cdkd alongside an existing `cdk deploy` workflow: no migration needed. You can also [import](#importing-existing-resources) existing stacks into cdkd or [export](#exporting-a-stack-back-to-cloudformation) back to CloudFormation anytime.
16
15
 
17
16
  **A natural fit for AI-driven development.** AI coding agents iterate in tight spin-up / tear-down loops — and cdkd keeps each turn short, with fast deploys and an equally fast `cdkd destroy` that deletes via direct SDK calls instead of polling a CloudFormation stack-delete.
18
17
 
18
+ **Local execution from your deployed stack.** `cdkd local` runs your functions, APIs, and ECS tasks on your machine. It can resolve env vars, secrets, and resource references from your real deployed stack: no hand-written `.env` files, no hand-seeded test data (see [Local execution](#local-execution)).
19
+
19
20
  > [!IMPORTANT]
20
21
  > cdkd is for dev/test workflows only — early in development, not yet production-ready.
21
22
 
23
+ ## Installation
24
+
25
+ ```bash
26
+ npm i -g @go-to-k/cdkd # latest release
27
+ npm i -g @go-to-k/cdkd@0.0.2 # pin to a specific version
28
+ ```
29
+
30
+ The installed binary is `cdkd`.
31
+
32
+ ## Quick Start
33
+
34
+ > **First-time setup**: run `cdkd bootstrap` once per AWS account before any
35
+ > other command; it replaces `cdk bootstrap`, which cdkd does not require
36
+ > (details in [Prerequisites](#prerequisites)).
37
+
38
+ ```bash
39
+ # Bootstrap (creates S3 state bucket + asset storage — one-time setup per AWS account)
40
+ cdkd bootstrap
41
+
42
+ # List stacks in the CDK app
43
+ cdkd list
44
+
45
+ # Deploy your CDK app
46
+ cdkd deploy
47
+
48
+ # Deploy at maximum speed: skip slow stabilization waits
49
+ cdkd deploy --no-wait
50
+
51
+ # Check what would change
52
+ cdkd diff
53
+
54
+ # Tear down
55
+ cdkd destroy
56
+ ```
57
+
22
58
  ## Benchmark
23
59
 
24
60
  **cdkd deploys up to 15x faster than AWS CDK (CloudFormation)** on SDK-Provider-handled stacks; the per-stack speedup widens with size and parallelism.
@@ -72,68 +108,6 @@ Distribution analysis, wait-skipping comparability (Terraform has no global `--n
72
108
 
73
109
  The full benchmark suite lives in [docs/benchmarks.md](docs/benchmarks.md): the SDK Provider path (**5.5x**, 17.0s vs 94.4s), the VPC + CloudFront + Lambda stack behind the headline **15x** (40s vs 599s with `--no-wait`), the Cloud Control API fallback path (**1.6x**), and the Terraform comparison in full detail. Reproduction scripts: [tests/benchmark](tests/benchmark/README.md).
74
110
 
75
- ## Prerequisites
76
-
77
- - **Node.js** >= 20.0.0
78
- - **AWS credentials with admin-equivalent permissions** for the resources being deployed. cdkd does NOT route through CloudFormation, so CDK CLI's `cdk-hnb659fds-deploy-role-*` is NOT sufficient — see [`--role-arn`](docs/cli-reference.md).
79
-
80
- AWS CDK's `cdk bootstrap` is not required. Instead, run `cdkd bootstrap` once per
81
- account: it creates everything cdkd needs, and per-region asset storage is added
82
- automatically on the first `cdkd deploy` into each region. Existing setups,
83
- legacy-mode opt-outs, and how this relates to `cdk bootstrap`: see
84
- [Upgrading from an earlier cdkd version](#upgrading-from-an-earlier-cdkd-version).
85
-
86
- ## Installation
87
-
88
- ```bash
89
- npm i -g @go-to-k/cdkd # latest release
90
- npm i -g @go-to-k/cdkd@0.0.2 # pin to a specific version
91
- ```
92
-
93
- The installed binary is `cdkd`.
94
-
95
- ## Quick Start
96
-
97
- > **First-time setup**: cdkd requires a one-time `cdkd bootstrap` per AWS
98
- > account before any other command will work — it creates the S3 state
99
- > bucket (`cdkd-state-{accountId}`) that cdkd uses to track deployed
100
- > resources, plus cdkd-owned asset storage for the region
101
- > (by default a `cdkd-assets-{accountId}-{region}` bucket +
102
- > `cdkd-container-assets-{accountId}-{region}` ECR repo — custom names via
103
- > `--asset-bucket` / `--container-repo`, skip with `--no-assets`; see
104
- > [`cdkd bootstrap`](docs/cli-reference.md#cdkd-bootstrap)).
105
- > This replaces `cdk bootstrap`, which cdkd does not require — see
106
- > [Prerequisites](#prerequisites).
107
-
108
- ```bash
109
- # Bootstrap (creates S3 state bucket + asset storage — one-time setup per AWS account)
110
- cdkd bootstrap
111
-
112
- # List stacks in the CDK app
113
- cdkd list
114
-
115
- # Deploy your CDK app
116
- cdkd deploy
117
-
118
- # Check what would change
119
- cdkd diff
120
-
121
- # Tear down
122
- cdkd destroy
123
- ```
124
-
125
- That's it. cdkd reads `--app` from `cdk.json` and auto-resolves the state bucket from your AWS account ID (`cdkd-state-{accountId}`). If you bootstrapped under a previous cdkd version, the legacy region-suffixed name (`cdkd-state-{accountId}-{region}`) is still picked up automatically with a deprecation warning.
126
-
127
- ### Upgrading from an earlier cdkd version
128
-
129
- **No breaking change, no manual step: just deploy.** The first `cdkd deploy` into
130
- each region auto-creates the cdkd-owned asset storage (interactive runs are asked
131
- once per region, `--yes` / CI runs create it automatically) and shows a one-time
132
- in-place UPDATE repointing asset references — content identical, no replacement.
133
- Downgrading is safe too (older binaries ignore the marker). Explicit pre-provisioning
134
- (`cdkd bootstrap --region <r>`), legacy-mode opt-outs, and how this relates to
135
- `cdk bootstrap`: see [`cdkd bootstrap`](docs/cli-reference.md#cdkd-bootstrap).
136
-
137
111
  ## Features
138
112
 
139
113
  - **Synthesis orchestration**: CDK app subprocess execution, Cloud Assembly parsing, context provider loop
@@ -196,6 +170,35 @@ For a step-by-step walkthrough of the full `cdkd deploy` pipeline (CLI
196
170
  parsing → synthesis → asset publishing → per-stack deploy), see
197
171
  [docs/architecture.md](docs/architecture.md#5-end-to-end-pipeline-walkthrough-cdkd-deploy).
198
172
 
173
+ ## Prerequisites
174
+
175
+ - **Node.js** >= 20.0.0
176
+ - **AWS credentials with admin-equivalent permissions** for the resources being deployed. cdkd does NOT route through CloudFormation, so CDK CLI's `cdk-hnb659fds-deploy-role-*` is NOT sufficient — see [`--role-arn`](docs/cli-reference.md).
177
+
178
+ AWS CDK's `cdk bootstrap` is not required. Instead, run `cdkd bootstrap` once per
179
+ account: it creates the S3 state bucket (`cdkd-state-{accountId}`) that cdkd uses
180
+ to track deployed resources, plus cdkd-owned asset storage (by default a
181
+ `cdkd-assets-{accountId}-{region}` bucket + a
182
+ `cdkd-container-assets-{accountId}-{region}` ECR repo; custom names via
183
+ `--asset-bucket` / `--container-repo`, skip with `--no-assets`; see
184
+ [`cdkd bootstrap`](docs/cli-reference.md#cdkd-bootstrap)). Per-region asset
185
+ storage is added automatically on the first `cdkd deploy` into each region.
186
+ Existing setups, legacy-mode opt-outs, and how this relates to `cdk bootstrap`: see
187
+ [Upgrading from an earlier cdkd version](#upgrading-from-an-earlier-cdkd-version).
188
+
189
+ ### Upgrading from an earlier cdkd version
190
+
191
+ **No breaking change, no manual step: just deploy.** The first `cdkd deploy` into
192
+ each region auto-creates the cdkd-owned asset storage (interactive runs are asked
193
+ once per region, `--yes` / CI runs create it automatically) and shows a one-time
194
+ in-place UPDATE repointing asset references — content identical, no replacement.
195
+ Downgrading is safe too (older binaries ignore the marker). If you bootstrapped
196
+ under a previous cdkd version, the legacy region-suffixed state bucket name
197
+ (`cdkd-state-{accountId}-{region}`) is still picked up automatically with a
198
+ deprecation warning. Explicit pre-provisioning
199
+ (`cdkd bootstrap --region <r>`), legacy-mode opt-outs, and how this relates to
200
+ `cdk bootstrap`: see [`cdkd bootstrap`](docs/cli-reference.md#cdkd-bootstrap).
201
+
199
202
  ## Usage
200
203
 
201
204
  cdkd has three command families:
@@ -1,4 +1,4 @@
1
- import { E as clearOnUpdateRemoval, L as normalizeAwsTagsToCfn, an as ResourceUpdateNotSupportedError, j as disableInstanceApiTermination, mn as __exportAll, rn as ProvisioningError, z as assertRegionMatch } from "./deploy-engine-C44YX-go.js";
1
+ import { E as clearOnUpdateRemoval, L as normalizeAwsTagsToCfn, an as ResourceUpdateNotSupportedError, j as disableInstanceApiTermination, mn as __exportAll, rn as ProvisioningError, z as assertRegionMatch } from "./deploy-engine-D30XI_UX.js";
2
2
  import { n as getLogger, u as generateResourceName } from "./logger-BYMEE-BS.js";
3
3
  import { EC2Client } from "@aws-sdk/client-ec2";
4
4
  import { AttachLoadBalancerTargetGroupsCommand, AttachLoadBalancersCommand, AttachTrafficSourcesCommand, AutoScalingClient, CreateAutoScalingGroupCommand, CreateOrUpdateTagsCommand, DeleteAutoScalingGroupCommand, DeleteLifecycleHookCommand, DeleteNotificationConfigurationCommand, DeleteTagsCommand as DeleteTagsCommand$1, DescribeAutoScalingGroupsCommand, DescribeLifecycleHooksCommand, DescribeNotificationConfigurationsCommand, DescribeTrafficSourcesCommand, DetachLoadBalancerTargetGroupsCommand, DetachLoadBalancersCommand, DetachTrafficSourcesCommand, DisableMetricsCollectionCommand, EnableMetricsCollectionCommand, PutLifecycleHookCommand, PutNotificationConfigurationCommand, UpdateAutoScalingGroupCommand } from "@aws-sdk/client-auto-scaling";
@@ -810,4 +810,4 @@ function mapNotificationsToCfn(configurations) {
810
810
 
811
811
  //#endregion
812
812
  export { asg_provider_exports as n, ASGProvider as t };
813
- //# sourceMappingURL=asg-provider-c0TMaGXW.js.map
813
+ //# sourceMappingURL=asg-provider-2hct1hkv.js.map