#tsc --init with comments

43 messages · Page 1 of 1 (latest)

golden coyote
#

Hello, I understand with typescript 5.9 the decision was made to change the tsc --init command to simplify it and remove the full list of options with comments. The release notes at https://www.typescriptlang.org/docs/handbook/release-notes/typescript-5-9.html say: "In TypeScript 5.9, a plain tsc --init with no other flags will generate the following tsconfig.json". The wording of this makes me think that there might be an extra flag I can use to get the original behavior with full option inclusion with corresponding comments, but looking at https://www.typescriptlang.org/docs/handbook/compiler-options.html I don't see anything that may apply. Is there a way to enable the old behavior?

I generally maintain a typescript example repo on my machine to reference the init tsconfig, copying from it for my projects and maintaing the order/separation/comments. Would like to continue doing this; had to downgrade my example repo to 5.8 to grabe erasableSyntaxOnly recently.

Documentation - TypeScript 5.9

TypeScript 5.9 Release Notes

Documentation - tsc CLI Options

A very high-level overview of the CLI compiler options for tsc

stable pilot
#

@golden coyote Doesn't appear that there is

golden coyote
#
  • No one likes the huge wall of text
  • Not many people like the commented-out options, and certainly not the "terrible idea" commented-out options

Call me Odysseus on the island of the Cyclopes I guess >.>

#

Reading down that, does seem like others complained and they're taking it into consideration. That markdown piping workaround is super onerous though

stable pilot
#

There's a few people who didn't like the change (most people who like a change don't go into the thread to argue about it)

#

He suggested filing a follow-up, but I don't see a linked ticket so I'm not sure anyone cared enough to even do that. (Though if you're thinking about doing that, make sure to look more carefully)

golden coyote
#

I'll check this weekend. Does the project use a separate ticketing system or is it just make an issue?

topaz karma
#

I do agree with using the docs. When there are new options/existing options get updated, your generated tsconfig is stuck with outdated and potentially wrong information.

#

(Unless you are willing to go around every single repo you have and keep their tsconfig comments up to date all the time)

golden coyote
#

And again, I keep a separate folder for referring to this "master" config. It's as simple as npm install typescript@latest, name the current tsconfig.json to like old-tsconfig.json, run npx tsc --init, and diff the files

topaz karma
#

Quite the dedication.

golden coyote
#

Is it? Seems way easier than checking the website docs and deciphering what changed

stable pilot
#

TBH, not really. TS release notes are excellent

#

I actually recommend people read older release notes just because they're such a good source of information on Typescript

#

And generally, prefer keeping TS config more minimal, using @tsconfig/bases and then just modifying the specific stuff that each repo needs.

golden coyote
#

Reading the release notes is easy enough, it's more that I like having an authoritative source for what order compiler options go in, what categories they're grouped in, and what comment should accompany them. I get that I can get a lot of this from the site documents and the --help --all command, but not in a format that's as easy to replicate as CTRL+C and CTRL+V

stable pilot
#

If you keep the tsconfig simple you don't have to worry about trying to keep them in a consistent order/grouping.

#

And I don't think the point of tsc --init was to have an "authoritive order/grouping".

golden coyote
#

I paid for all the compiler options, I'm gonna use all the compiler options 😛

#

(The price was free)

humble harness
#

ah i guess there's a comment in the new generated tsconfig pointing to that, so most likely you are

#

@golden coyote what did you do about all the options that weren't mentioned in the generated tsconfig before? despite being massive, the old one wasn't exhaustive

golden coyote
#

Yeah, aware of it, and was what I was referring to "site documents". As far as options not in the unit config, never ran into any of what I used. My biggest section was always type checking, with emit following close behind I guess. Though thanks for bringing that up and making me look through it; if I'm enabling erasableSyntaxOnly, that probably includes experimentalDecorators and I should remove that. Wonder if that affects something like Nest.js

humble harness
#

it's been a bit since i've had to touch Nest.js, but last time i did it required experimentalDecorators

#

if you don't mind, can you share an example of one of your tsconfig files? i'm kinda curious what all you configure. mine aren't typically much more involved than this. i find the default values for other options are mostly what i want, but since it sounds like you're much more in tune with the configuation space than i am maybe you'll help me find things i've been missing

golden coyote
# humble harness if you don't mind, can you share an example of one of your tsconfig files? i'm k...

Here you go! I also set outDir and typeDir, but I usually do Turborepo monorepos, and because extending a tsconfig still resolves the outdir/typedir to the path of the original tsconfig, I set that in the extending tsconfig
https://gist.github.com/0mn1core/1a9cdc2e77f881d49ac8d0ec2704050b

Gist
General typescript config

General typescript config. GitHub Gist: instantly share code, notes, and snippets.

#

Actually need to figure out some changes for mine, I found out my .d.ts was including javascript code, and I accidentally imported from that instead of the real generated js file. The compiler didn't complain, the runtime obviously did, and was going crazy trying to debug it

humble harness
#

my .d.ts was including javascript code
wait what? you have runtime code in a .d.ts file? is this a file you wrote yourself?

#

i generally recommend not hand-writing .d.ts files unless you are specifically providing types for untyped JS code. especially if you set "skipLibCheck": true

golden coyote
humble harness
#

same for strict. "strict": true doesn't do anything other than set defaults for a bunch of other options

#

i'm mostly curious about how you chose this middle ground. i'd kinda get it if you were completely exhaustive (though personally that's now how i'd go), but for example, given your config: useDefineForClassFields is implicitly true (because of "target": "ESNext") but you haven't written that out explicitly, resolvePackageJsonExports and resolvePackageJsonImports are implicitly true (because of "moduleResolution": "NodeNext") but you haven't written them out explicitly, etc

#

ugh my "f" key is apparently dying on this keyboard

golden coyote
#

It looks like module sets moduleResolution, but no reciprocal behavior.

Strict I would keep set to true even if setting all the strict properties individually, to catch new stuff on version upgrade

It's been a while since I examined my config in-depth, knowing now those options that are set as part of ESNext/NodeNext, I'll probably set those in my config now with comments.

I get the exhaustive-ness probably seems crazy, but if my IDE or compiler yells at me for something, I want the explicit rule in my config file for me to reference the comment line on, not me going crazy trying to figure out why a rule is being applied if it's not in my config

humble harness
#

the logical conclusion would be to explicitly set all 100-odd options (or at least the non-deprecated ones). like i said i would kinda understand that (though IMO it doesn't seem worth the tradeoffs of extra maintenance burden and making the config file hard to scan, though the latter could maybe be solved by putting the "important" options at the top or in a separate referenced tsconfig file)

#

i thought you had some heuristic to decide which options are "important enough" to explicitly include, but it doesn't seem like it?

#

according to the schema there are 119 compilerOptions (i was curious what the real number was). there are other config options too, but i think you're mostly focused on compilerOptions

#

that's a lot of config. i don't envy the TS team having to manage this giant configuration space