chore(iac): adopt TypeScript 6.0.3 — tested, unlike the 7.0 proposal - #29
Merged
Conversation
Dependabot opened TypeScript 6.0.3 (#28) right after the 7.0 investigation. Tested the same way, and it came out differently: 6.0.3 tsc --noEmit exit 0 · 8/8 stack tests · cdk synth 9 stacks -> ADOPTED 7.0.2 tsc --noEmit exit 0, but ALL 8 stack tests die at startup: TypeError: Cannot read properties of undefined (reading 'fileExists') `ts-node` works with TS 6 and not with TS 7, which is the native rewrite that no longer exposes the `ts.sys` JS surface ts-node reads its tsconfig through. So the `>= 7` ignore added in #27 is drawn at the measured break point rather than at "no major upgrades", and this is the upgrade it was always going to allow through. Worth recording: the implicit-`@types` removal — the cause of the 7 x TS2591 "Cannot find name 'process'" errors seen during the 7.0 test — actually landed in **6.0**, not 7. Verified by removing `types: ["node"]` under 6.0.3 and watching them come back. So the one-line tsconfig fix shipped in #27 is precisely what unblocked this upgrade. It was correct on its own terms before either upgrade was attempted, which is the useful shape: making an implicit dependency explicit paid off one major earlier than expected. Also documented in this branch, with evidence, a HIGH Dependabot alert that CANNOT be fixed right now: brace-expansion 5.0.8 (needs 5.0.9) at node_modules/aws-cdk-lib/node_modules/brace-expansion, inBundle=true `aws-cdk-lib@2.263.0` is the latest published version and it bundles the vulnerable copy. Both remediation routes were tested and neither works: `npm audit fix` reports `fixAvailable: true`, runs, and leaves the lockfile byte-identical; an `overrides: {"brace-expansion": "^5.0.9"}` also leaves it at 5.0.8, because overrides cannot reach inside a third-party bundled tarball. This is the same shape as the earlier bundled-CVE work. It clears when upstream publishes a cdk-lib that bundles 5.0.9 — there is no action available to this repository, and claiming otherwise would be the "fixAvailable" lie repeated. Tested: 3711 passed / 6 skipped (unit + regression); IaC E2E under TS 6 — tsc exit 0, 8/8 stack tests, cdk synth 9 stacks; ruff clean; make ci green.
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.
Dependabot opened TypeScript 6.0.3 right after the 7.0 investigation in #27. Tested the same way — and it came out differently.
tsc --noEmitcdk synthTS 7 fails with
TypeError: Cannot read properties of undefined (reading 'fileExists'): it is the native rewrite and no longer exposes thets.sysJS surfacets-nodereads its tsconfig through.ts-nodeworks fine with TS 6.So the
>= 7ignore added in #27 is drawn at the measured break point, not at "no major upgrades" — and this is the upgrade it was always going to allow through. Supersedes #28.The part worth recording
The implicit-
@typesremoval — the cause of the 7 ×TS2591 Cannot find name 'process'errors seen during the 7.0 test — actually landed in 6.0, not 7. Verified by removingtypes: ["node"]under 6.0.3 and watching them come back.So the one-line tsconfig fix shipped in #27 is precisely what unblocked this upgrade. It was correct on its own terms before either upgrade was attempted — making an implicit dependency explicit paid off one major earlier than expected.
A HIGH alert that cannot be fixed, documented rather than papered over
aws-cdk-lib@2.263.0is the latest published version and it bundles the vulnerable copy. Both remediation routes were tested and neither works:npm audit fixreportsfixAvailable: true, runs, and leaves the lockfile byte-identicaloverrides: {"brace-expansion": "^5.0.9"}also leaves it at 5.0.8 — overrides cannot reach inside a third-party bundled tarballSame shape as the earlier bundled-CVE work in this repo. It clears when upstream publishes a cdk-lib bundling 5.0.9. There is no action available here, and claiming otherwise would just repeat npm's own
fixAvailablelie.Testing
tsc --noEmitexit 0 · 8/8 stack tests via ts-node ·cdk synth9 stacksruffclean ·make cigreen (lint / coverage ≥88 / iac synth / secret-scan)