feat(cli): typescript init templates use tsc + tsx and swc/jest, on typescript 7#1719
Merged
Conversation
Contributor
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.OpenSSF Scorecard
Scanned Files
|
cee7dd8 to
a6be7a1
Compare
a6be7a1 to
392f284
Compare
… ts-node
TypeScript 7.0.2 (the first stable release of the Go-based compiler) was
published on 2026-07-08. ts-node@10 reads the compiler's ts.sys API, which
TypeScript 7 no longer exposes, so the generated project's 'cdk synth'
crashes for anyone who upgrades — and the init-typescript-app integ test
matrix (enumerated live from npm) began failing on every PR the moment 7.0
appeared:
TypeError: Cannot read properties of undefined (reading 'fileExists')
at readConfig (.../ts-node/dist/configuration.js:91:33)
Rather than swapping in another third-party transpiler, drop the runner
entirely. The app command becomes:
npx tsc && node bin/<name>.js
tsc exits non-zero on type errors, so 'cdk synth' still fails on type
errors exactly as it did with ts-node — with two template tweaks to keep
that property sound:
- noEmitOnError, so a failed compile can't leave stale JS behind that a
subsequent synth would silently run
- an explicit types list (jest, node). TypeScript 6.0 changed the default
of the 'types' option to [] (packages under node_modules/@types are no
longer auto-included, per the TS 6.0 release notes). The template's test
file uses jest globals, so a generated project whose owner upgrades to
TS >= 6 fails to compile without this field — a latent break independent
of ts-node (previously hidden at synth time because ts-node only
compiled the bin/lib import graph; tsc compiles the whole project).
Verified in isolation: same project compiles on 5.9, fails identically
on 6.0 and 7.0 without the field, passes on all three with it. Note the
version-matrix CI test itself never hits this (it deletes test/ before
building); the field protects real users, not CI.
Test changes: the version-matrix test no longer installs any runner (just
the matrix's typescript version), and the devDependencies-stripping step
now also strips the tsconfig types list — with @types/jest removed, tsc
would otherwise error on the missing type package.
Verified end-to-end with a locally built CLI: init + synth under the pinned
typescript ~5.9, then again after upgrading the generated project to
typescript@7.0.2 — both clean; ts-node crashed on the latter. Full matrix
flow (strip devDependencies, install matrix version, build, run) verified
under 6.0 and 7.0; TypeScript 3.9 accepts the tsconfig option values.
Contributor
|
Wait, isn’t the problem that ts-node doesn’t support TS7? Then why are we/they pulling it in? |
mrgrain
requested changes
Jul 9, 2026
| @@ -1,5 +1,5 @@ | |||
| { | |||
| "app": "npx ts-node --prefer-ts-exts bin/%name%.ts", | |||
| "app": "npx tsc && node bin/%name%.js", | |||
Contributor
There was a problem hiding this comment.
I was thinking this:
Suggested change
| "app": "npx tsc && node bin/%name%.js", | |
| "app": "npx -c \"tsc && tsx bin/%name%.js\"", |
Contributor
Author
There was a problem hiding this comment.
Switched to tsc && tsx. Per our conversation, tsx is faster than ts-node anyway, and tsc is faster than it used to be, and now feasible here.
Contributor
Author
It's automatically pulled in from NPM when we run our cli-integ test matrix, per the following logic: Anything newer than 2 years old is pulled in. |
…ypescript 7 TypeScript 7 drops the ts.sys API that ts-node and ts-jest rely on. Replace both with tooling that doesn't depend on compiler internals: - App execution: npx tsc (type-check only, noEmit) && npx tsx (esbuild) - Tests: @swc/jest (transpile-only; npm run build still type-checks) - Pin typescript to ~7.0.2 across all three TS templates (app, sample-app, lib) - Add explicit types: ["jest", "node"] to lib/typescript tsconfig (required since TS 6+ no longer auto-includes all @types) - Version-matrix integ test installs tsx alongside the matrix typescript version
Contributor
Author
|
Integ tests are passing on all tested version of typescript (released within 2 years). |
rix0rrr
approved these changes
Jul 10, 2026
mrgrain
approved these changes
Jul 10, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
TypeScript 7.0.2 was published on 2026-07-08.
ts-node@10reads the compiler'sts.sysAPI, which TypeScript 7 no longer exposes, and ts-node has no compatible release.ts-jest@29likewise caps its peer dependency attypescript <7. Two consequences:typescriptpast~5.9crashes oncdk synth:init-typescript-appinteg test enumerates TypeScript versions live from npm, so7.0entered the matrix immediately and theinteg_init-templatesjobs fail on every PR.This PR moves the TypeScript init templates to TypeScript 7 and replaces the compiler-API-dependent tooling:
npx tsc && npx tsx bin/<name>.ts—tsctype-checks (noEmit), then tsx (esbuild-based) runs the app. Follows @mrgrain's review suggestion, with plainnpxchaining instead ofnpx -cfor portability across npm versions and Windows.@swc/jest(transpile-only, no type checking). Faster thants-jest, which we also can't use with TypeScript 7 due tots-jestdepending onts-node. Type errors intest/are still caught bynpm run build, since the tsconfig includes the test directory.Neither tsx nor swc drives the TypeScript compiler API, so the templates no longer break when the compiler's internals change.
Template changes
Made changes to typescript templates as follows:
For
app+sample-apptypescript variantscdk.template.json: use app commandnpx tsc && npx tsx bin/<name>.tspackage.json: dropts-nodeandts-jest; addtsx,@swc/core,@swc/jesttsconfig.json: addnoEmit,isolatedModules(esbuild transpiles file-by-file), and an explicittypes: ["jest", "node"]list — TS 6+ no longer auto-includes all ofnode_modules/@typesjest.config.js: transform@swc/jestREADME:build/watchdescriptions now say "type-check" sincetscno longer emitsFor
libtypescript variantnoEmit, since there is noappcommand.Test changes
tsxalongside the matrix'stypescriptversionVerified locally with a built CLI
typescript@7.0.2:npm installresolves,npm run buildpasses under the Go-based compiler,npm testpasses through@swc/jest, and the app command runs end to endnpx tscwith exit 1, blocking synthUser-facing notes
cdk initgenerates for new projects.tscstill type-checks every synth, but tsx (esbuild) executes the app, so synth and watch iterations are faster than ts-node's compiler-API path.npm run buildcovers that.By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license