[X-Guardian]

Description

cdktn init --template=typescript-pnpm scaffolds a TypeScript project managed by pnpm. Until now --template=typescript hardcoded npm everywhere: the install in the sscaff hook, the package.json scripts, the help text, and the post-convert npm run get. A pnpm user ended up with a package-lock.json beside their pnpm-lock.yaml, and cdktn provider add on a pnpm project ran npm install. The project itself moved to pnpm in #170.

Stored as a variant. typescript/ is the one TypeScript template; its help, package.json and cdktf.json take their commands from the template variables pmRun, pmAdd and pmExec, and its hook checks for, installs with, and pins the manager named by packageManager. typescript-pnpm/ carries only pnpm-workspace.yaml, which approves the build scripts of the template's dependencies (pnpm 11 fails the install otherwise). TEMPLATE_VARIANTS in cli-core/init.ts maps the variant to its base plus those four strings; it is the only name-keyed table, and --dist validation and the --from-terraform-project gate resolve through it. init() makes one sscaff call on the base; the base hook's post copies the variant directory into the project right before installing, so a failed prerequisite check (missing or too-old pnpm) writes nothing and anything already in the directory is untouched, while an install failure keeps the scaffolded files. The pnpm template requires pnpm 10.26 or newer (allowBuilds) and does not need npm on PATH.

The CLI resolves the package manager from the project, not the template name. detectNodePackageManager(dir) in @cdktn/commons reads the packageManager field first (corepack), then pnpm-lock.yaml, .yarnrc.yml, yarn.lock, else npm. provider add and provider list use it (pnpm add -E, pnpm list --json --depth 0), so does the post-convert run get in cdktn init, and so does cdktn debug, so there is one detector and remote templates get the right command too. Quiet flags are emitted per manager: pnpm has no --no-progress, Yarn Berry rejects both.

Yarn. Yarn classic (1.x) is archived upstream; Yarn Berry (2+) is not supported by this CLI. Both now print a one-time warning pointing to #492, which documents what works and fails on Berry, the workarounds, and the projen route. On Berry, provider list, provider upgrade and debug fail with a clear usage error instead of a confusing yarn list failure; provider add keeps working. The typescript-yarn template proposed in the first revision of this PR is dropped (see the thread). Vote on #492 if you need native Berry support.

Integration test. test/typescript/init-pnpm-template scaffolds the template, synthesizes it, adds a pre-built provider through pnpm and lists it through the pnpm listing path, and covers three failure modes through a shimmed pnpm: too old and missing (directory left empty), and an install failure (scaffolded files kept).

Four pre-existing bugs fixed in passing, each a one-liner met while testing this path:

• helper/init.ts built an ExecSyncOptions (including stdio: "ignore" under --silent) and never passed it, so --silent leaked output from the post-convert run get.
• init() never passed cdktfVersion to providerAdd, so cdktn init --cdktf-version=X --providers=aws scaffolded and then failed with cannot use version 0.0.0.
• The --from-terraform-project warning said "the typescript template" where several now qualify.
• jest.config.js annotated its config with ts-jest's deprecated InitialOptionsTsJest.

Relates to #79: this adds one template through the overlay system rather than a full copy, and does not change the direction discussed there.

Telemetry

Template names flow into the init telemetry automatically. Recording the detected package manager in usage metrics is a follow-up once #411 lands.

Checklist

• I have updated the PR title to match CDKTN's style guide
• I have run the linter on my code locally
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation if applicable (follow-up: list typescript-pnpm in the init docs)
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works if applicable
• New and existing unit tests pass locally with my changes

🤖 Generated with Claude Code

[sakul-learning]

Reviewed 648dc2acbbc3. Builds and the configured test targets pass; one path introduced by the new yarn template is broken.

typescript-yarn: provider listing goes through a Yarn 1-only command

templates/typescript-yarn/.hooks.sscaff.js pins packageManager: yarn@<current 4.x> into the generated package.json, and the new detection getter in packages/@cdktn/cli-core/src/lib/dependencies/package-manager.ts:281 prefers that field, so listProviderPackages() (:444) routes yarn projects to listYarnPackages() (:356), which runs yarn list --json. Yarn 2+ (Berry) removed list:

$ yarn list --json
Usage Error: Couldn't find a script named "list".

exec in @cdktn/commons rejects on a non-zero exit, so listYarnPackages throws, getCurrentlyInstalledVersion rethrows it as Failed to list packages: (dependency-manager.ts:193), and allProviders (:503) propagates. In a project scaffolded with --template=typescript-yarn, cdktn provider list, cdktn provider upgrade and cdktn debug all fail. cdktn provider add is unaffected — it never lists, and yarn add -E does work on Berry.

It only fails in the configuration the template is aiming for: without corepack the pin cannot switch versions, Yarn 1.22 performs the install, and yarn list --json works.

Berry does have an equivalent — yarn info --name-only --all --json returns "@cdktn/provider-random@npm:15.0.0", one JSON string per line — so this needs a Berry branch plus an update to yarnListSchema (:168), which currently expects {data:{trees:[…]}}.

Two smaller items

1. templates/typescript/.hooks.sscaff.js:9 adds exports.pre = () => requirePackageManager("npm"), and sscaff runs pre on every pass, so --template=typescript-pnpm and --template=typescript-yarn still require npm on PATH even though they install with pnpm/yarn. The isOverlayBase guard only exists in post; sscaff passes the variables to pre, so the check can move there.
2. The added tests cover detection only. The new per-manager quiet-flag branch in NodePackageManager.addPackage (:324) — npm pushes --silent --no-progress, pnpm --silent, yarn neither — and the pnpm listing path have no coverage. Both are pure argument construction and cheap to test.

[X-Guardian]

I'll leave this PR here for you to do with what you want then.

My personal view is that currently cdktn init is broken for the package manager it uses itself, pnpm which is a bit embarrassing. This is just two variants on the typescript template, following the python/python-pip pattern already in place. You are talking as if there have been lots of templates added, which is not correct.

[so0k]

I'll leave this PR here for you to do with what you want then.

My personal view is that currently cdktn init is broken for the package manager it uses itself, pnpm which is a bit embarrassing. This is just two variants on the typescript template, following the python/python-pip pattern already in place. You are talking as if there have been lots of templates added, which is not correct.

sure, I'd remove yarn and keep the pnpm fixes. I am reluctant to touch cdktn init is all - I highlighted this in past PRs that work on the init templates

EDIT:

• cdktn-cli: Simplify init templates #79
• fix(cli): Pin init template to TypesScript 5.x #74

but I'll wait for Jon's opinion if we keep Yarn (and fix the commands) or just stick to pnpm (as pointed out we use pnpm for this project).

[jsteinich]

• I don't think we should add a yarn template - it doesn't seem popular enough to warrant its inclusion
• I can see the argument for adding pnpm as we do use it with the project
• I'd really like to see the addition of new templates being driven by actual community requests for it. @X-Guardian perhaps this does serve as your request, but it's not clear that you'd actually be using the template from your comments.
• In the past I would use init for reproducing reported bugs; however, these days AI can set up a full reproduction projection much easier. For real projects, I just copy an existing one (yes, I know projen was designed to handle that flow). I'm not sure what other's experiences are, but it seems like we should find out before decided to invest time into init expansions / improvements.
• If we do add a new template, we should add integration tests to ensure that it actually functions correctly.

[jsteinich]

A few things from a pass over the pnpm path; details inline.

[so0k]

Follow-up, not for this PR: python and python-pip are full copies, and the variant mechanism introduced here would collapse them the same way.

What actually differs between them: the app command in cdktf.json (pipenv run python main.py versus python3 ./main.py), the run line and the provider-install paragraph in help, and in the hook the probe (pipenv versus pip3) and the install step (three pipenv install calls versus writing requirements.txt and pip3 install). main.py and .gitignore are byte-identical. main-test.py has already drifted: the pipenv copy has a commented-out stack and assert True, the pip copy constructs a real TerraformStack. That drift is the cost the variant mechanism removes.

Shape of the change: python/ becomes the base with {{ pm* }} placeholders and one hook branching on ctx.packageManager; python-pip/ carries nothing (or a requirements.txt seed), and Pipfile stays the pipenv-only file, the equivalent of pnpm-workspace.yaml. Same ordering (variant first, base installs last). The python hooks currently process.exit(1) from pre, which bypasses sscaff's error path and the rollback in init(); moving them to throw belongs in the same change.

Tracking under #79.

[sakul-learning]

packages/@cdktn/cli-core/src/lib/init.ts:118-134 can delete pre-existing user files when the TypeScript/pnpm base preflight fails.

checkForEmptyDirectory() deliberately permits dotfiles/directories and README.md. The variant pass adds pnpm-workspace.yaml, but variantFiles = fs.readdirSync(destination) then snapshots every destination entry, including pre-existing ones. If the base pre hook rejects missing or old pnpm before writing another file, baseWroteNothing is true and the cleanup loop calls fs.removeSync() on every snapshotted entry.

A common destructive path is:

1. git init
2. cdktn init --template typescript-pnpm without pnpm, or with pnpm < 10.26
3. the base preflight fails
4. cleanup recursively removes both pnpm-workspace.yaml and the pre-existing .git directory

The same applies to .env, .gitignore, .vscode/, and README.md. The exported init() API can also receive a non-empty destination without the CLI guard.

Could the rollback snapshot the destination before rendering the variant, then remove only paths newly created by the variant? A regression test should create an allowed pre-existing sentinel—ideally .git/HEAD, plus .env or README.md—trigger a missing/old-pnpm failure, and verify that the sentinel survives while pnpm-workspace.yaml is removed. This is a data-loss blocker for the current sequencing.