Skip to content

esm: doc & validate source values for formats - #32202

Closed
bmeck wants to merge 6 commits into
nodejs:masterfrom
bmeck:specify-esm-source-decoding
Closed

esm: doc & validate source values for formats#32202
bmeck wants to merge 6 commits into
nodejs:masterfrom
bmeck:specify-esm-source-decoding

Conversation

@bmeck

Copy link
Copy Markdown
Member
Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • documentation is changed or added
  • commit message follows commit guidelines

This better specifies how decoding of source values returned from loaders are translated. Some formats expect different types of sources. This also fixes some problems where Buffers were properly decoding due to the custom .toString but typed arrays were not.

We could expand the tests if desired, but I felt just checking Uint8Array was sufficient.

@bmeckbmeck added the esm Issues and PRs related to the ECMAScript Modules implementation. label Mar 11, 2020

@GeoffreyBoothGeoffreyBooth left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Looks good other than the docs note. Thanks for doing this!

Comment threaddoc/api/esm.md Outdated
of the following:

| `format` | Description |
| `format` | Description | Acceptable Source Values |

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Maybe it's just me, but I read this as "the source value of format", e.g. that 'builtin' should be a string. I think what you mean is the acceptable type of source returned by getSource for this format? So maybe call this "Acceptable Types for getSource Returned source"?

Should we also update the signature in getSource?

@returns{string|buffer}response.source

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

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

Yes, I meant the value from either getSource OR transformSource

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Okay, do you mind making that clearer? Maybe “Acceptable Types For source Returned by getSource or transformSource”?

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

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

done, also made sure to actually check both hooks rather than just transformSource

@guybedfordguybedford left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Nice to see this being locked down well.

@GeoffreyBooth

Copy link
Copy Markdown
Member

Do we need to update the JSDoc function signatures? e.g.

@returns{string|buffer}response.source

@nodejs-github-bot

Copy link
Copy Markdown
Collaborator

@GeoffreyBooth

Copy link
Copy Markdown
Member

@bmeck ☝️ #32202 (comment) do we need to fix this too?

@bmeck

bmeck commented Mar 23, 2020

Copy link
Copy Markdown
MemberAuthor

@GeoffreyBooth We could, but overall the signature isn't trivial and I think Buffer|string is the most likely realistic return value people want to know about. It would be ideal if we had something more sane to explain all the coercions code does in core (like what WebIDL provides), but we don't in core for now :(.

@bmeck

Copy link
Copy Markdown
MemberAuthor

rebased and looks green locally, will CI then land if green and no comment in next few hours

@bmeck
bmeckforce-pushed the specify-esm-source-decoding branch from 44fcb28 to a3a01f4CompareMarch 23, 2020 15:29
@bmeck

Copy link
Copy Markdown
MemberAuthor

rebase had a minor change, in particular I had to update ./test/fixtures/es-module-loaders/transform-source.mjs to handle if it gets a buffer back for a module format.

@nodejs-github-bot

Copy link
Copy Markdown
Collaborator

@addaleax

Copy link
Copy Markdown
Member

@bmeck Didn’t look into the other failures but at least the linter is complaining

@bmeck
bmeckforce-pushed the specify-esm-source-decoding branch from a3a01f4 to cd5ccdfCompareMarch 31, 2020 16:15
@nodejs-github-bot

Copy link
Copy Markdown
Collaborator

@bmeck

Copy link
Copy Markdown
MemberAuthor

Fixed lint, CI errors seem unrelated

@nodejs-github-bot

Copy link
Copy Markdown
Collaborator

@nodejs-github-bot

Copy link
Copy Markdown
Collaborator

@targos

Copy link
Copy Markdown
Member

Test error without intl:

assert.js:103
throw new AssertionError(obj);
^
AssertionError [ERR_ASSERTION]: These modules were unexpectedly loaded:
NativeModule string_decoder
at Object.<anonymous> (/home/iojs/build/workspace/node-test-commit-linux-containered/test/parallel/test-bootstrap-modules.js:134:8)
at Module._compile (internal/modules/cjs/loader.js:1176:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1196:10)
at Module.load (internal/modules/cjs/loader.js:1040:32)
at Function.Module._load (internal/modules/cjs/loader.js:929:14)
at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:71:12)
at internal/main/run_main_module.js:17:47 {
generatedMessage: false,
code: 'ERR_ASSERTION',
actual: [Set],
expected: [Set],
operator: 'deepStrictEqual'
}

@bmeck
bmeckforce-pushed the specify-esm-source-decoding branch from ae2427c to 01af9cdCompareMay 18, 2020 18:03
@bmeck
bmeckforce-pushed the specify-esm-source-decoding branch from 01af9cd to 614ec8eCompareMay 18, 2020 18:04
Comment threaddoc/api/esm.md Outdated
Co-authored-by: Derek Lewis <DerekNonGeneric@inf.is>
Comment threaddoc/api/esm.md Outdated
Co-authored-by: Derek Lewis <DerekNonGeneric@inf.is>
@nodejs-github-bot

Copy link
Copy Markdown
Collaborator

Comment threaddoc/api/esm.md Outdated

@DerekNonGenericDerekNonGeneric left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Although much of this is new material to me, the previous layout didn't really make sense to me. :/

My suggestions are how I've made sense of it, but I could be wrong. I hope we can improve this little area, it's a rather important section for those implementing types on the function boundaries of the custom loader hooks API.

Comment threaddoc/api/esm.md Outdated
Comment threaddoc/api/esm.md
bmeckand others added 3 commits May 19, 2020 14:02
Co-authored-by: Derek Lewis <DerekNonGeneric@inf.is>
Co-authored-by: Derek Lewis <DerekNonGeneric@inf.is>
Co-authored-by: Derek Lewis <DerekNonGeneric@inf.is>
@nodejs-github-bot

Copy link
Copy Markdown
Collaborator

@nodejs-github-bot

Copy link
Copy Markdown
Collaborator

CI: https://ci.nodejs.org/job/node-test-pull-request/31448/

himself65 pushed a commit that referenced this pull request May 21, 2020
PR-URL: #32202
Reviewed-By: Guy Bedford <guybedford@gmail.com>
Reviewed-By: Geoffrey Booth <webmaster@geoffreybooth.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Zeyu Yang <himself65@outlook.com>
@himself65

Copy link
Copy Markdown
Member

landed in cd4985c

codebytere pushed a commit that referenced this pull request Jun 18, 2020
PR-URL: #32202
Reviewed-By: Guy Bedford <guybedford@gmail.com>
Reviewed-By: Geoffrey Booth <webmaster@geoffreybooth.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Zeyu Yang <himself65@outlook.com>
@codebyterecodebytere mentioned this pull request Jun 28, 2020
codebytere pushed a commit that referenced this pull request Jul 8, 2020
PR-URL: #32202
Reviewed-By: Guy Bedford <guybedford@gmail.com>
Reviewed-By: Geoffrey Booth <webmaster@geoffreybooth.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Zeyu Yang <himself65@outlook.com>
@codebyterecodebytere mentioned this pull request Jul 13, 2020
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

esmIssues and PRs related to the ECMAScript Modules implementation.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants

@bmeck@GeoffreyBooth@nodejs-github-bot@addaleax@targos@himself65@guybedford@DerekNonGeneric@bfarias-godaddy