Skip to content
This repository has been archived by the owner on Sep 2, 2023. It is now read-only.

Draft esm resolver specification #207

Closed
wants to merge 3 commits into from
Closed

Conversation

guybedford
Copy link
Contributor

In line with the current plans for Phase 2 I've put together a draft resolver algorithm here that includes the new properties from the minimal kernel implementation.

The goal is, like the minimal kernel, to start with what we have agreed on, and to expand this over time as we can reach consensus.

This one brings up the discussions around the package.json main handling.

Would be nice to discuss this at the meeting today if there is time, although I understand it is late notice to read up on the details here.

@devsnek
Copy link
Member

devsnek commented Oct 24, 2018

I think a better place for this would be doc/esm.md in our repo

@guybedford
Copy link
Contributor Author

@guybedford
Copy link
Contributor Author

@devsnek good point, I can redraft the PR there.

@jkrems
Copy link
Contributor

jkrems commented Oct 24, 2018

I think having a more formal spec here that we can harden and then turn it into a more user-facing documentation makes sense. doc/esm.md is user documentation, not spec imo.


The algorithm to resolve an ES module specifier is provided through _ESM_RESOLVE_:

ESM_RESOLVE(specifier, parentURL)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we copy the beginning from the HTML spec even though the observable behavior should be the same?

  1. Apply the URL parser to specifier. If the result is not failure, return the result.
  2. If specifier does not start with the character U+002F SOLIDUS (/), the two-character sequence U+002E FULL STOP, U+002F SOLIDUS (./), or the three-character sequence U+002E FULL STOP, U+002E FULL STOP, U+002F SOLIDUS (../), return <our custom logic>.
  3. Return the result of applying the URL parser to specifier with base URL as the base URL.

That ways it's a bit easier to tell where we deviate from what would happen in a browser.

@guybedford
Copy link
Contributor Author

Per @devsnek's suggestion I've created a PR at https://github.com/nodejs/ecmascript-modules/pull/12/files. Since we are keeping these docs maintained on the minimal implementation I think that would make sense given that the specification for the CommonJS resolver is user-facing documentation.

@guybedford
Copy link
Contributor Author

Closing this PR for now, let's continue discussion on the ecmascript-modules repo rather then.

@guybedford guybedford closed this Oct 24, 2018
@ljharb ljharb deleted the esm-resolver-spec branch October 24, 2018 15:55
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants