cdktf-init typescript template general QOL improvements

[acdoussan]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

• Please update the default template to output the built .js / .d.ts files from typescript to a build folder (aka set outDir to build), rather than dumping them next to the code. These files clutter up the folder and I don't want to see them.
• Support absolute paths by default. Ref: https://discuss.hashicorp.com/t/cdktf-tsconfig-paths-not-working-for-local-imports/46163/6?u=acdoussan
• It would be nice if the initial project setup was slightly more sophisticated, rather than having everything in a single file. I propose creating a src directory, which contains an app.ts file and a exampleStack.ts file. main.ts instantiates the app from app.ts, app.ts instantiates the stack from exampleStack.ts, exampleStack.ts can stay empty as it is in the current template. Example on what this would look like can be seen in this issue.

References

https://www.typescriptlang.org/tsconfig#outDir

[xiehan]

Hi @acdoussan, thanks for the detailed issue writeup! For the first two bullet points, I'll let the engineers weigh in since they can say more about whether there are any consequences to making these changes or not.

As for your third bullet point, I get where you're coming from, but unfortunately we're not likely to incorporate this proposed change at this time. The reason being is that since we're a relatively new project and lots of folks are still learning to use CDKTF for the first time, it's very important for us to be consistent between the library itself and our documentation and tutorials located at e.g. https://developer.hashicorp.com/terraform/tutorials/cdktf/cdktf-install and https://developer.hashicorp.com/terraform/cdktf/examples-and-guides/refactoring. These docs make heavy use of this "all of your config in a single file" pattern because it's much easier to convey the documentation that way even though it's not a desirable pattern for more complex, production-grade projects.

Down the line, the team is talking about refactoring the entire template system to make it more robust, and I wonder if that time might be an opportunity for us to look into maintaining our current simple "quickstart" template but also add more advanced templates that might be more suitable for production projects. For now, however, it is more important for us to keep CDKTF accessible for beginners, and rely on our more experienced users to figure out for themselves how to refactor the default template to better suit complex use cases.

[fbartho]

@xiehan I understand the desire to simplify the learning curve a few years ago when this project started.

That's said, this is 2025 now, and the points that @acdoussan raised initially are friction points that I have to bypass when advocating for this tool with my team.

Can we revisit this decision in light of the age of the project now?

[fbartho]

Filed a related quality of life issue: #3827