[jsteinich]

Related issue

Fixes #78

Stacked on #395 — review/merge that first. Both branches live on a fork, so GitHub will not accept #395's branch as this PR's base; it targets main instead, which means the diff currently also contains #395's two commits (53dfa1d jsii 6, 3a4e69f rosetta in the test harness). Once #395 merges, this diff reduces on its own to just the two template commits below.

Review only f2670da and bc85bb4 here.

Description

Two commits, separable if you'd prefer:

1. Replace ts-node with tsx (f2670da)

cdktn synth runs the app through ts-node, and ts-node cannot be used with
TypeScript 6. When a project leaves moduleResolution unset, ts-node merges a
bundled @tsconfig/nodeXX default that supplies node10, and passes it as an
explicitly specified option — which TypeScript 6 rejects:

TS5107: Option 'moduleResolution=node10' is deprecated and will stop
functioning in TypeScript 7.0

Setting moduleResolution in the project's own tsconfig does not help: ts-node
overrides it. Instrumenting CI showed the project resolving Node16 under
tsc while ts-node still resolved Node10 from the same config.

This is not a passing problem. ts-node has had no release since v10.9.2
(December 2023) and no commit to main since that month; its maintainer has
been seeking sponsorship to restart development since October 2024
(TypeStrong/ts-node#2140), and it is already broken outright on TypeScript 7
(TypeStrong/ts-node#2174).

tsx is actively released, has overtaken ts-node in weekly downloads, and is the
runner Node's own documentation uses
to demonstrate full TypeScript support. It is already a devDependency in this
repository via @cdktn/hcl2cdk.

Trade-off: tsx transpiles without type checking, so cdktn synth no longer type
checks the app. npm run build / npm run compile still do, and this matches
how the repository runs its own tests (@swc/jest).

2. Move the template to TypeScript 6 (bc85bb4)

typescript@5.x becomes >=5.0.0 <7.0.0. Two config changes are required:

• types: ["node", "jest"] — TypeScript 6 no longer picks up ambient @types
  automatically, so describe/it stopped resolving.
• isolatedModules — ts-jest 29.x cannot emit under TypeScript 6 in
  language-service mode (emitSkipped), so every suite fails to run. This puts
  it on transpileModule; npm run build still type checks.

Scope

Template only. Existing projects keep ts-node in their cdktf.json and are
unaffected until they move to TypeScript 6, at which point they need the same
one-line change — worth a changelog note. The test/typescript/*/cdktf.json
fixtures still pin npx ts-node main.ts; migrating those is left as a
follow-up so this diff stays easy to read.

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
• 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

Verified on a generated project against TypeScript 5.4.5, 5.9.3 and 6.0.3 —
tsc, jest and cdktn synth all pass on each:

TS 6.0.3   build=OK jest=PASS synth=OK
TS 5.9.3   build=OK jest=PASS synth=OK
TS 5.4.5   build=OK jest=PASS synth=OK

🤖 Generated with Claude Code

[sakul-learning]

One non-blocking suggestion on the two new Java dependency declarations — the fix itself is correct and necessary (jsii 6 publishes these at provided scope, so the generated imports sources no longer receive them transitively), but the Gradle scope could mirror provided more closely.

packages/@cdktn/cli-core/templates/java/build.gradle declares:

implementation "javax.annotation:javax.annotation-api:1.3.2"
implementation "org.jetbrains:annotations:19.0.0"

and examples/java/gradle-shared-module/common/build.gradle declares:

api 'javax.annotation:javax.annotation-api:1.3.2'
api 'org.jetbrains:annotations:19.0.0'

jsii-pacmak publishes both artifacts at Maven provided scope, i.e. compile-only: javax.annotation-api is SOURCE-retention (absent from bytecode) and org.jetbrains:annotations is CLASS-retention with no runtime behavior. Gradle's analog of provided is compileOnly:

compileOnly "javax.annotation:javax.annotation-api:1.3.2"
compileOnly "org.jetbrains:annotations:19.0.0"

The practical difference:

• implementation (template) adds these to the runtime classpath, and because templates/java/build.gradle applies maven-publish with from(components.java), a generated project's published POM would carry them as runtime-scope dependencies.
• api (shared-module example) additionally exports them to every consumer of the common module's compile and runtime classpaths.

compileOnly supplies them exactly where they're needed — compiling the generated imports sources — without the runtime/public-dependency surface.

Not a blocker: all three scopes compile the generated sources (the @examples/java-gradle-shared-module integration test is green), so this is just a small dependency-footprint cleanup if you'd like to match the provided contract exactly.

[jsteinich]

Thanks — applied, both are now compileOnly.

Agreed on the reasoning: javax.annotation.Generated is SOURCE-retention and the JetBrains annotations are CLASS-retention, so neither needs to be on the runtime classpath, and compileOnly is the honest analog of Maven's provided. Your point about maven-publish + from(components.java) leaking them into a generated project's published pom as runtime deps is the part I'd missed — that's a real difference for every project created from the template, not just a footprint nicety.

One thing I checked before switching the example from api, since compileOnly is not transitive: in gradle-shared-module only common declares terraformProviders, so it is the only module with generated imports sources. module-a and module-b declare none and merely consume common's types, which needs no annotations on their compile classpath. So dropping the export is safe here — noted in a comment on the change so it does not get "fixed" back later.

Also in this push: the 28 integration fixtures under test/ were still pinning npx ts-node main.ts in their cdktf.json while TestDriver provisions them via cdktn init, which no longer installs ts-node. Switched those to tsx as well.

[so0k]

Approving. One non-blocking finding and a sequencing note.

Non-blocking: inaccurate range comment

packages/@cdktn/cli-core/templates/typescript/.hooks.sscaff.js:31-33

// Mirrors the `constructs` peer dependency range declared by the cdktn
// package. Keep both in sync.
installDeps([npm_cdktf, `constructs@10`], false, silent);

The two are not equivalent: constructs@10 permits 10.0.0 onward, while the cdktn peer range is ^10.6.0. A fresh install resolves the newest 10.x, so there is no runtime defect — but the "mirrors / keep in sync" instruction is misleading for whoever maintains it next. Either drop the mirroring claim or state the actual relationship (the template intentionally installs a wider spec and relies on the peer range to bound it).

The shortened comments beside the Java compileOnly dependencies keep the rationale that matters (generated import sources need the annotations; jsii 6 publishes them at provided scope; the shared common module is the only one generating sources) — good shrink.

Sequencing

This branch contains #395's commits and targets main (its diff is a superset of #395), so #395 merges first. Since the repo squash-merges, this branch will need a rebase onto main once #395 lands; happy to do that push (maintainer edits are enabled).

[github-actions]

I'm going to lock this pull request because it has been closed for 30 days. This helps our maintainers find and focus on the active issues. If you've found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.