Skip to content
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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

[wip] export maps and builtins #2

wants to merge 1 commit into from

Conversation

mikeal
Copy link
Owner

@mikeal mikeal commented Dec 10, 2019

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.

@mikeal mikeal changed the title init: initial thoughts on a schema for export maps [wip] initial thoughts on a schema for export maps Dec 10, 2019
@mikeal mikeal changed the title [wip] initial thoughts on a schema for export maps [wip] export maps and builtins Dec 10, 2019
file &File
deps PackageMap
builtins optional [String]
}
type Exports struct {
Copy link

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.

Copy link

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

Copy link
Owner Author

@mikeal mikeal Dec 10, 2019

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.

Copy link
Owner Author

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.

Copy link

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.

Copy link
Owner Author

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?

Copy link

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.

Copy link
Owner Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants