tsc --init-basic

[benwainwright]

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.

[benwainwright]

I've now forked the repo and worked out how to make this change. I appreciate the issue is still to be accepted; if not, no worries, I'll consider a useful exercise in introducing myself to a codebase I'd like to contribute in.

If you believe this feature has enough value for my contribution to be included, the remaining guidance I need in order to finish my patch are on these areas:

• I've run the tests following my changes. And the baseline tests fail because of the changed output related to the new flag. In the contributing guide, it says "At least one test should fail in the absence of your non-test code changes". Do the baselines count? If not, where would tests around this issue live. The changes I've made are mostly in src/compiler/commandLineParser.ts. The corresponding test file doesn't appear to have anything related to this functionality, and nothing that wasn't a baseline failed when I added my flag, so it doesn't look like the --init flag is specifically tested beyond the baseline (that I can see)
• to generate the correct message in the help screen, I had to add to the diagnostics json file. I can see that the number of the original 'init' description is 6070. None of the numbers around that point are free so I had to go to the bottom of the file to find a code that was free. Is there any significance behind these numbers; is there any issue with it I've found the documentation on this, will look for a free 6xxx series code
• the flag name I've gone with is --initSimple. I'm not precious about this, though shorter is better (which is why I didn't go with --initWithoutComments). Any alternatives will be happily accepted.
• is there any documentation that needs to be updated with this change?

[fatcerberus]

At least one test should fail in the absence of your non-test code changes

I think this is just a fancy way of saying “If you make a code change, you should write (or modify) one or more tests for it, and at least one of the new tests must fail without your change.”

It doesn’t mean your change has to cause existing tests to fail, although of course it may, in which case that has to be dealt with too.

[andrewbranch]

FWIW I’ve always wanted this feature, but I’m not confident that a PR would get accepted and I would hate to see you burned by infinite bikeshedding as a first time contributor. If this feature is your passion, don’t let me stop you from implementing it, but be prepared that a PR for an “awaiting more feedback” issue may or may not ever get a proper review. If you are just looking to start contributing to TS anywhere, I would encourage you to search for “help wanted” and “good first issue” labels, where you’re much more likely to get support with a PR from start to finish.

[benwainwright]

I would hate to see you burned by infinite bikeshedding as a first time contributor. If this feature is your passion, don’t let me stop you from implementing it, but be prepared that a PR for an “awaiting more feedback” issue may or may not ever get a proper review

I mean passion is a strong way of putting it. I believe this change is a no brainer given the ratio of effort to value... but if the PR isn't accepted I'll live as I can just continue copying from my other projects 🤷🏻‍♂️ . From a personal point of view it was a useful excuse to check out the code and understand how to make changes in tsc without having to do too much thinking.

[benwainwright]

If you are just looking to start contributing to TS anywhere, I would encourage you to search for “help wanted” and “good first issue” labels, where you’re much more likely to get support with a PR from start to finish.

I'm aware of this and have started digging through these tickets. But I've not yet found anything which I thought was suitable for my very limited understanding of the codebase yet (and wasn't already 'claimed'). This is a use case I fully understand (because it's for me) and the implementation is very accessible.

[andrewbranch]

Well, maybe to get some momentum one way or another: @MartinJohns, why are you not a fan?

[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.

[andrewbranch]

I think I create (and edit) more tsconfigs than the average person since a big part of my job is creating repros of bugs. I agree this isn’t a big value add, but if it existed, I would definitely use it and it would make me happy. On the other hand, I would personally not care about this at all if VS Code had a “strip all comments” command built in, as that would be just as fast for my workflow.

[benwainwright]

@MartinJohns

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.

For the record, since I've already implemented the change on a fork, I can tell you that the file is indeed generated dynamically and because of the way it is done, there is no risk of divergence.

and I'd say this flag brings no real benefit

I mean that's a matter of opinion I guess, but I do appreciate that there are other options.

@andrewbranch

On the other hand, I would personally not care about this at all if VS Code had a “strip all comments” command built in, as that would be just as fast for my workflow.

To be honest, I'm a vim user (yeah, sorry - one of those people 😉) and when you put it like that - it will probably take me about 20 minutes to write a vim mapping to do this. It just hadn't occurred to me that anyone would argue against this to be honest, since I've not yet worked with anyone who finds these kind of comments in config files useful at all, and plenty who find them annoying. I'd actually be very much in favour of just removing them outright, but I suspect that would be an even harder sell...

[orta]

I think I'd probably argue against this personally - especially given that @tsconfig/bases exists and at this point has a base for a lot of common JS projects.

I'd think I'd be open to tsc --init --extends which for example:

yarn tsc --init --extends @tsconfig/node14
Created a new tsconfig.json with:

  extends: @tsconfig/node14

You can learn more at https://aka.ms/tsconfig.json

cat tsconfig.json
{
    "extends": "@tsconfig/node14"
    "compilerOptions": {
      /* Visit https://aka.ms/tsconfig.json to read more about this file */
    }
}

This doesn't introduce a new concept to teach (e.g. there's new one flag which only works with --init) but instead extends the idea of 'you can set your own custom tsconfig options from the CLI' to also include extends.

[MartinJohns]

if VS Code had a “strip all comments” command built in, as that would be just as fast for my workflow.

@andrewbranch Well, technically VS Code has such a feature... Kind of, using "Replace" and a Regular Expression.

I quickly hacked together the Regular Expression I used and it's not the prettiest, but it works:
(\n\s+/\*.*(?!\*/))|(\n\s+//[^\n]*)|(\s+/\*.*(?!\*/))

[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̨̥̫͎̭ͯ̿̔̀ͅ

🚎

[benwainwright]

I think I'd probably argue against this personally - especially given that @tsconfig/bases exists and at this point has a base for a lot of common JS projects.

I'd think I'd be open to tsc --init --extends which for example:

yarn tsc --init --extends @tsconfig/node14
Created a new tsconfig.json with:

  extends: @tsconfig/node14

You can learn more at https://aka.ms/tsconfig.json

cat tsconfig.json
{
    "extends": "@tsconfig/node14"
    "compilerOptions": {
      /* Visit https://aka.ms/tsconfig.json to read more about this file */
    }
}

This doesn't introduce a new concept to teach (e.g. there's new one flag which only works with --init) but instead extends the idea of 'you can set your own custom tsconfig options from the CLI' to also include extends.

@orta that's actually a great idea. What do you think the likelihood of me getting that in if I were to have a go at implementing it?