tsc --init-basic

Suggestion

As a professional TypeScript developer, I start new TS projects all the time. I use tsc --init sometimes, but more often than not I copy tsconfig.json files from other projects because I find the tsconfig.json file that is generated to be horribly spammy.

Having a tsc --init command is valuable to me, because quite often I want to bootstrap a project quickly, but the comments get in my way, as they make it harder to read what the actual config of a project is, and generally look really messy. If I ever run tsc --init the first thing I do is strip out these comments.

I’d really appreciate a tsc --init-basic (or something like it) that provides the same basic configuration set but without any comments.

• Note; I suspect this would be super simple to implement, and I’m looking for opportunities to start contributing, so if anyone can point me towards the appropriate area in the codebase, I’d be happy to submit this change myself.

🔍 Search Terms

tsconfig comments init

✅ Viability Checklist

My suggestion meets these guidelines:

• This wouldn’t be a breaking change in existing TypeScript/JavaScript code
• This wouldn’t change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn’t a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript’s Design Goals.

[fatcerberus]

I quickly hacked together the Regular Expression I used and it’s not the prettiest, but it works

ZA̡͊͠͝LGΌ ISͮ̂҉̯͈͕̹̘̱ TO͇̹̺ͅƝ̴ȳ̳ TH̘Ë͖́̉ ͠P̯͍̭O̚​N̐Y̡ H̸̡̪̯ͨ͊̽̅̾̎Ȩ̬̩̾͛ͪ̈́̀́͘ ̶̧̨̱̹̭̯ͧ̾ͬC̷̙̲̝͖ͭ̏ͥͮ͟Oͮ͏̮̪̝͍M̲̖͊̒ͪͩͬ̚̚͜Ȇ̴̟̟͙̞ͩ͌͝S̨̥̫͎̭ͯ̿̔̀ͅ

🚎

[MartinJohns]

@andrewbranch I’m generally opposing any new flags or options that bring no real benefit, and I’d say this flag brings no real benefit. It adds bloat (code and feature wise) and is just another option to do the same thing, causing slight fragmentation. Also there’s a possible risk of those two init configs diverging, although I believe the code already is smarter than that and the file(s) would be / is generated dynamically.

If a lot of people consider this a value worth adding, I’d say go ahead. But for a few individual cases there are plenty of alternative options (e.g. extending config from npm package, copy existing file, have a local command that generates the file), although these would have to be maintained to make use of new flags in newer versions.

I can see the appeal, but my gut feeling towards such features is a no.