Open RyanCavanaugh opened 4 months ago
Module options look good to me for Node.js / library authoring. I assume you’ve intentionally left in some redundancies so that good option A stays set if someone changes/removes option B that’s currently making A redundant. For good measure, a list of those:
--module nodenext
implies --target esnext
; you have it set to es2022
(seems good to keep it set as is)--module nodenext
implies --moduleDetection force
--verbatimModuleSyntax
implies --isolatedModules
(people are more likely to turn off the former)The one that’s missing from this good-but-redundant category is --module nodenext
implies --esModuleInterop
, which is a good idea to keep on, but the thing people are likely to switch to is --moduleResolution bundler
, which implies --allowSyntheticDefaultImports
, which is close enough. So not critical to add, I think.
TLDR looks good 👍
Though originally I was thinking more about include
over rootDir
, it makes sense given the guardrails rootDir
provides if you screw something up? And that's important given people try to do custom exclude
/include
rules that are often unnecessary.
So I'm generally in favor around outDir
and rootDir
. The thing I am curious about is if we can detect sensible conventions such as folder name and existence of a package.json
. This includes stuff like src
as a well-known input directory, and special casing depending on if you're running from inside src
.
👍 / 👎 ?
// Other outputs
// "declaration": true,
// "sourceMap": true,
Pretty much everybody is going to debug at some point, and it’s going to be bad until they realize they need to enable sourceMap
The only thing that sucks about having options commented out is you can't hover on them to see the description of what they do, which doesn't help when you don't know what something does and want to know if you should enable it. Unfortunately most options don't have an explicit setting that means "use the default behavior, whatever it happens to be today", so no easy solutions to be found here.
I could also suggest turning off allowUnreachableCode
. It greatly help in some circumstance.
Acknowledgement
Comment
Following up from #58417
Note: This is only for argumentless
tsc --init
. We know that it's physically possible to write text after--init
and that text could do something, but that's a separate issue. Sincetsc --init
should do something, this issue is only about what that something is.General consensus from the design meeting + external discussion:
"module": "commonjs"
is a hard noOther live issues:
39354 - set
types
to[]
- yes49206, #39308 - increase default target - also yes
39311 - set
udfcf
- I would argue moot by now since we should set the target high enough that this doesn't matter51207 - consult
package.json
- it's not obvious that yourpackage.json
is configured yet at the time you runtsc --init
, this seems marginalOther things we didn't get to:
rootDir
,outDir
: These are generally a good idea; no one likes the default side-by-side JS emit buuut there aren't strictly universal conventions hereProposed new output:
I tried to order this from "most likely to edit" to "least likely to edit"