-
Notifications
You must be signed in to change notification settings - Fork 3
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
[wip] export maps and builtins #2
base: master
Are you sure you want to change the base?
Conversation
file &File | ||
deps PackageMap | ||
builtins optional [String] | ||
} | ||
type Exports struct { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
exports can also be an object with properties (like a dot, for main) or a string, or an array of those.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://npmcdn.com/[email protected]/package.json may be helpful as a valid example
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this data structure is per-file (or per module in native ESM terms), so if there are exports for multiple endpoints they would get multiple data-structures, each with their own Exports
struct.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
to be clear, this export map swaps out the file returned for each native ESM module. if a package.json declares multiple endpoints then each of those files will get it’s own export map in order to branch on a file-by-file basis.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Gotcha, sorry for my misunderstanding.
There could, however, be multiple potential files for each specifier when "exports" is used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ljharb is that due to the fallback logic?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The fallback logic, and the upcoming conditional exports, will mean that different node versions and different environments and different module systems could all point to different files. They'll all be statically determinable, but there'll be 0, 1, or N files resulting from that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hrm... i’m fine with holding off on supporting the full spectrum since there’s other limitations that reg
already imposes on what you can and cannot do.
Starting to work through what it would take to support export maps since I think I’m going to need them for statically linking the standard library.
@MylesBorins curious if you have any thoughts. In particular, I’m wondering if there is every a case where I can’t locate a default file for export. Please @ anyone you think has thoughts on this.