Draft esm resolver specification #207
Conversation
|
I think a better place for this would be doc/esm.md in our repo |
|
@devsnek good point, I can redraft the PR there. |
|
I think having a more formal spec here that we can harden and then turn it into a more user-facing documentation makes sense. |
|
|
||
| The algorithm to resolve an ES module specifier is provided through _ESM_RESOLVE_: | ||
|
|
||
| ESM_RESOLVE(specifier, parentURL) |
There was a problem hiding this comment.
Should we copy the beginning from the HTML spec even though the observable behavior should be the same?
- Apply the URL parser to specifier. If the result is not failure, return the result.
- 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>.- 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.
|
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. |
|
Closing this PR for now, let's continue discussion on the ecmascript-modules repo rather then. |
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.