-
Notifications
You must be signed in to change notification settings - Fork 12.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Design Meeting Notes, 9/22/2021 #46012
Comments
This could be considerably easier if Node actually exposed the resolvers as an API rather than every tool having to reimplement the resolver logic. There have been comments around on Node issues about people being interested, but it might be worth making an explicit issue. |
I think given the fact that TypeScript has to lay its own But the complexity is more about supporting users, not supporting the logic ourselves. We can barely keep the whole thing in our heads, but we've spent years thinking about it, so we think there's a very small chance that a user would figure out the correct setup quickly on their own. |
I think the notes lost some context there—what I called “rocket science” was actually hand-authoring type definitions (e.g. for DefinitelyTyped) that work for a package that ships CJS and ESM side-by-side, and my point was that being able to redirect type resolution (to a separate module definition for each module kind) via export maps is going to be a super nice feature for us, and for type definition authors. (Also, rocket science was probably a bad analogy, since I assume that rocket science is meticulous, precise, and reliable 😬) |
Sorry @andrewbranch, that's what the notes were meant to reflect, but the convo was happening a bit too fast. I think the analogy was fine. Usually the idiom "it's not rocket science" implies "this is simple, so nobody should get overwhelmed by it" whereas this is something we don't think is simple, and thus can make no guarantees about whether anyone will be overwhelmed by it 😅 |
That seems fine IMO. If users adopt the new "node12" mode, they are opting into modern Node which has two resolvers. Being obliged to be explicit on type resolution seems a small price to pay for the win on clarity-of-intent for anyone reading the code, hopefully reducing head-spinning. It places the migration costs on the old code (which could be as simple as a one-time quick-fix), rather than polluting new code with oddities like import assertions. |
I kind of agree with this, and I don't think I was able to articulate @weswigham's response to this one. It sounded like the issue was with forcing users to migrate old code, but I think that old code has to get migrated as one big bang anyway, right? You can't have a sane story where you progressively convert some of your modules in an existing TypeScript codebase from CJS to ESM unless you start at the roots and switch your import statements to |
But there's a big "what is the default configuration?" story. The whole issue is that a TypeScript file today allows ESM |
I like that line of thinking. If My instinct says the one-time big-bang migration this imposes, at the point the project enables Would love to hear more from Wes about his original response. |
No - people have literally been asking for TS to be the tool that people lean on to ease the transition - not the thing that people use to be punished for node's support of ESM by being forced back into using old syntax. Many times I've been told "yeah, node's dual module strategy will be bad because technical reasons, but TS will bridge the gap, right?". There is no "big bang migration" caused by the new mode - in fact, there's likely no migration required at all for existing code. People have been using TS targeting cjs output for almost forever - having a modern version of TS's "node mode" break that behavior is a massive break in expectations. A key and very useful feature of the new node resolution is that, largely, if you have an existing I don't get why so many people central to parts of the node package community want to punish existing node package authors with forced migration. It's a nongoal for me. |
Also, that whole discussion on import assertions is about declaratiom emit and isn't a problem in non-declaration code. And it's a problem in declaration emit because we only have one type-space construction to look up package types |
Thanks Wes - so it's only for declaration code, and only for import types, where there's no current syntax to explicitly select a resolution. I think your first comment explains the justification for staying in the business of module transforms. |
Having been loosely keeping up with the TypeScript discussions around the new Node resolutions, I just wanna say thanks for putting in what is clearly a significantly amount of time and effort towards both getting things right and making things as user-friendly as possible! 😀 |
Binding Pattern Breaking Changes
#45846 (comment)
#46009
Motivation
Other more complex issues.
Why?
Best thing we can imagine is left-to-right completions for
Current proposal is to disable for object binding patterns, but re-enable contextual typing from array binding patterns.
We still don't fully understand the inferences - probably best to do that.
When we started doing implied types from binding patterns, we didn't have types apart from
any
- now havenever
andunknown
.Let's do a full revert and think through this a bit more.
Node ESM Support
#44501
weswigham#67
weswigham#68
New resolution modes:
node12
andnodenext
CJS and ESM files can resolve files via different paths based on the syntax and containing file.
This is "solved" albeit complicated, but what is not solved is...
Import type syntax:
.d.ts
files.So how do you differentiate between "this should resolve as ESM vs CJS"?
Could have a different conditions passed into
import(...)
types.import("foo", { /*conditions*/ })
Why does this matter?
import "lodash"
andrequire("lodash")
can fetch TWO DIFFERENT FILES innode_modules/lodash/
.Technically the MVP doesn't need to include this...but it will likely be an issue.
If you need to reference a type in ESM, either in
.d.ts
emit or by-hand, can you just writeCan you lean on
import()
types always getting inferred from containing context?import()
s an ESM.Import assertions affecting module resolution?
Seems like a no-no, but might need to use sibling conditions as a way to bypass that.
Heavy regret of not introducing
require()
types; now you need a "realimport
type" type.Whole thing is such a 🤬😫😢😭
What if we just didn't let you write
import
in a non-module file?require()
in CJSmodule: node12
, but as far as they're concerned they're still doing CJS.If our heads are spinning from this, users' will too.
Stripping out complexity?
"maybe I'm just old and grumpy"
We should be able to explain the happy path to people.
We have a lot of concern over how easily we'll be able to communicate best practices here; this is not just something that can affect TypeScript, the complexity can significantly hurt Node.js too.
The text was updated successfully, but these errors were encountered: