You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Uhhhh but...that could change already does exist and changed.
Let's say it does change in the future - how do you opt into the old behavior?
Is there potential for shifting behavior to "bork" an existing program?
So node12 as well?
Should have these match.
What about a rolling node-esm flag that accumulates more?
node-next?
node14 could come out, etc. so node-next could be that rolling target.
Is there an official name?
No, it's just an update in the docs really.
Could ask for a name?
The name is there, it's Node 12 😄
Could module and moduleResolution be one flag?
module toggles a specific moduleResolution
Do we need a new moduleResolution flag?
Yeah.
Is node backwards-compatible?
Ehhh, they layer on the existing behavior.
But if you continue following the existing resolution rules (e.g. main field in package.json), you'll get the wrong behavior.
Kind of weird that package.jsons have more and more of our configuration.
Sounds like node12 for both
Eventually node-next or node-esm or something along those lines.
So "module": "node12" implies "moduleResolution": "node12".
Emit
Implementation strategy: don't want to ship in stable with a partial implementation - lots of moving parts.
What other things do we have to support?
.cjs
.mjs
Unfortunate reality in Node.
Potentially not used all that often, but users keep asking about them even though there's "type": "module".
Under that, we have a path forward for .ts -> .js which is still good.
But still need .mjs output. So .mts?
What about .mtsx?
What if you just have .mts?
.mts just supports JSX, doesn't support <AngleBracketCastSyntaxOn>values
Also type parameter lists with no constraint or trailing comma.
constf=<T>(t: T)=>{};// no good, have to rewrite asconstf=<Textendsunknown>()=>{}constf=<T,>()=>{}
What about .tsx for modules?
Well, doesn't generate an .mjs.
API isn't set up to disambiguate.
Feels bad to say "JSX is allowed in this file."
.mtx? 🤯
Supporting multiple extensions: we can do that, but we have special support include and exclude globs being specialized for TypeScript. Already got burned by this with JSON files.
How realistic would it be for us to say "no .mts and .cts"?
Probably for a bit, but we would inevitably get demand.
Still could start with something prescriptive. Maybe don't do it until we get an absolute need, along with a better sense of how people will organize their projects.
Our own experience: sometimes when you're in ESM fully, with "type": "module", you'll end up with times that you want to break out.
If you want to use native ESM with Electron, you need to break out and jump into CJS land to get require
Maybe .cts is more important than .mts.
Is there a way to say "this is CJS in a package.json?"
Nope.
You can put it in a sub-folder with a package.json that says "type": "whatever-is-not-module".
File extension madness! Can't imagine the cost of .cts, .cd.ts, etc.
We already use readDirectory, luckily it's not too bad anymore.
Luckily, a lot of resolution "just works" today but we need module disambiguation with modules.
We can start working on this, but we will not ship until we feel feature-complete. ✅
Performance
Our team has been working hard off thinking about how to help speed up TypeScript, and to help big projects scale.
Lots of anecdotes
One internal team switched from 1100 projects to way fewer. Hour-long compilation goes from 10 minutes.
Massive React projects that use project references.
Much of the time, projects incorrectly set up. Our bad, we had poor docs.
Often look for hot spots in check time - didn't see it.
React's ComponentProps - maybe takes 500ms to check?
If you have 100 projects that have to re-check this thing over and over, that's like 50 seconds on that one declaration alone.
ES Modules in Node
https://gist.github.com/weswigham/22a064ffa961d5921077132ae2f8da78
Resolution Settings
exports
,types
,typesVersions
types@VERSION_SPECIFIER
moduleResolution
flagnode12
module
target flag?node
that could changealready does exist and changed.node12
as well?node-esm
flag that accumulates more?node-next
?node14
could come out, etc. sonode-next
could be that rolling target.module
andmoduleResolution
be one flag?module
toggles a specificmoduleResolution
moduleResolution
flag?node
backwards-compatible?main
field inpackage.json
), you'll get the wrong behavior.package.json
s have more and more of our configuration.node12
for bothnode-next
ornode-esm
or something along those lines."module": "node12"
implies"moduleResolution": "node12"
.Emit
.cjs
.mjs
"type": "module"
..ts
->.js
which is still good..mjs
output. So.mts
?.mtsx
?.mts
?.mts
just supports JSX, doesn't support<AngleBracketCastSyntaxOn>values
Also type parameter lists with no constraint or trailing comma.
What about
.tsx
for modules?.mjs
.API isn't set up to disambiguate.
.mtx
? 🤯include
andexclude
globs being specialized for TypeScript. Already got burned by this withJSON
files..mts
and.cts
"?"type": "module"
, you'll end up with times that you want to break out.require
.cts
is more important than.mts
.package.json
?"package.json
that says"type": "whatever-is-not-module"
..cts
,.cd.ts
, etc.readDirectory
, luckily it's not too bad anymore.Performance
ComponentProps
- maybe takes 500ms to check?--incremental
/--watch
needs to compute shape. Declaration emit happens twice. Initial build mode build emits twice #43995.typeToTypeNode
? #44043, Fix logic for determining whether to simplify keyof on mapped types #44042imports
that weren't there.import type
, bam, make everyone feel better.The text was updated successfully, but these errors were encountered: