Change layout of default TypeScript project & bump typescript base configuration

[rantoniuk]

Describe the feature

I'd like to suggest the following improvements to the cdk init app --language typescript template:

• add "outDir": "dist" to tsconfig.json - this will allow all rendered files to be cleanly separated in a separate directory instead of mixing in the typescript source directories
• add dist to .gitignore and remove patterns of ignoring .js files as this will be unneeded with the above

Additionally I have a question about:

    "target": "ES2018",
    "module": "commonjs",
    "lib": [
      "es2018"
    ],

Is this still the case for cdkv2 (i.e. does it still depend on Node 12?)

How about moving to Node14 or 16 and using es2020 via https://github.com/tsconfig/bases/blob/main/bases/node14.json instead?

Happy to hear your thoughts.

Use Case

I'm actually investigating this as I have trouble using npm link correctly between a construct library and a consumer library for development and it seems that tsconfig configuration can be one of the issues.

Proposed Solution

No response

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

CDK version used

2.8.0

Environment details (OS name and version, etc.)

MacOS, Node 14/16

[indrora]

There's two parts here: An engineering practice question ("to dist & .gitignore or not") and an SDLC question ("What version of Node/ECMA/TS are we going to support")

W/r/t "to dist & .gitignore or nay", I would say that since it's mostly a matter of "change this in your config file and be done with it", we can cross that bridge when we get there.

However, the SDLC question is a larger one. Right now, we've got a few unknowns and a few weird edge cases. The first is that TypeScript has no documentation on what "supported" versions there are. I've opened a ticket with the TypeScript folks some time ago asking to document this.

Currently, I believe the "minimum" version of Node that is supported is 12, still, despite Node 12 being EOL ( https://nodejs.org/en/about/releases/ no longer lists it, as it went EOL in April 2022 ). I have no problems running the CDKv2 on Node 18 (what Brew ships as of current).

Just as a point of reference, the current version of NodeJS shipped by various distributions:

• MacPorts: Each major release has its own package.
• HomeBrew: node@18, but node@16 and node@14 are still available.
• Debian: node16 in bookworm (stable) and node12 in bullseye (oldstable)
• Ubuntu: node12 in Jammy (22LTS)
• Fedora: EPEL, Rawhide, and current releases (35/36) all shipping node16. Signs point to Node18 shipping with Fedora 37.

Wow that's a mess! Tools like nvm make some of that less of a pain, but nvm itself is... fraught with issues (nvm officially does not want to be shipped via distribution package managers such as Brew).

A larger conversation on "What's the bare minimum supported version of Typescript/ecma that we're supporting" is in order however. I'm not sure specifically but I (read/heard/hallucinated) that part of the blocker was JSII and its support for modern JS features. For pure TypeScript projects, I don't think that's an issue?

@rix0rrr and @MrArnoldPalmer probably have better insight into that than me, however...

[MrArnoldPalmer]

yeah the version of TS that is used to compile the CDK is not necessarily limiting the version typescript users of the CDK need to build their projects since, as you mentioned, JSII is the limiting factor and TS app authors do not need to use JSII (only construct library authors wishing to publish in multiple languages). So that being said we could update the version of TS in our application init templates to be the latest stable version.

As far as creating a dist directory and building out of source, I think we have largely agreed that that is a better practice than in source builds and we would likely be in favor of that as well.

Also, CDK does only support node 14+ now so targeting ES2020 is likely also fine, though I'm wondering what the benefits of this would be? Are we missing out on certain features/performance with es2018 targets @rantoniuk?

[kjpgit]

@rantoniuk Thank you for suggesting outDir... I set that up today and my project is so much less cluttered, and my autocomplete in vim & bash isn't messed up from those js/d.ts files.... I don't know why this wasn't made the default, especially in CDK 2.

[oste]

I am also decluttering with outDir today and curious of any caveats and why it wasn't chosen as a default. The .d.ts and .js files add a lot of clutter to the project