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

esm: doc & validate source values for formats #32202

Closed
wants to merge 6 commits into from

Conversation

bmeck
Copy link
Member

@bmeck bmeck commented Mar 11, 2020

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.

@bmeck bmeck added the esm Issues and PRs related to the ECMAScript Modules implementation. label Mar 11, 2020
Copy link
Member

@GeoffreyBooth GeoffreyBooth left a comment

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!

doc/api/esm.md Outdated

| `format` | Description |
| `format` | Description | Acceptable Source Values |
Copy link
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
Member Author

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
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
Member Author

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

Copy link
Contributor

@guybedford guybedford left a comment

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
Member

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

@returns {string|buffer} response.source

@nodejs-github-bot
Copy link
Collaborator

@GeoffreyBooth
Copy link
Member

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

@bmeck
Copy link
Member Author

bmeck commented Mar 23, 2020

@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
Member Author

bmeck commented Mar 23, 2020

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

@bmeck bmeck force-pushed the specify-esm-source-decoding branch from 44fcb28 to a3a01f4 Compare March 23, 2020 15:29
@bmeck
Copy link
Member Author

bmeck commented Mar 23, 2020

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
Collaborator

@addaleax
Copy link
Member

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

@bmeck bmeck force-pushed the specify-esm-source-decoding branch from a3a01f4 to cd5ccdf Compare March 31, 2020 16:15
@nodejs-github-bot
Copy link
Collaborator

@bmeck
Copy link
Member Author

bmeck commented Mar 31, 2020

Fixed lint, CI errors seem unrelated

@nodejs-github-bot
Copy link
Collaborator

@nodejs-github-bot
Copy link
Collaborator

@targos
Copy link
Member

targos commented May 9, 2020

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 bmeck force-pushed the specify-esm-source-decoding branch from 01af9cd to 614ec8e Compare May 18, 2020 18:04
doc/api/esm.md Outdated Show resolved Hide resolved
Co-authored-by: Derek Lewis <[email protected]>
doc/api/esm.md Outdated Show resolved Hide resolved
Co-authored-by: Derek Lewis <[email protected]>
@nodejs-github-bot
Copy link
Collaborator

doc/api/esm.md Outdated Show resolved Hide resolved
Copy link
Contributor

@DerekNonGeneric DerekNonGeneric left a comment

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.

doc/api/esm.md Outdated Show resolved Hide resolved
doc/api/esm.md Show resolved Hide resolved
bmeck and others added 3 commits May 19, 2020 14:02
Co-authored-by: Derek Lewis <[email protected]>
Co-authored-by: Derek Lewis <[email protected]>
Co-authored-by: Derek Lewis <[email protected]>
@nodejs-github-bot
Copy link
Collaborator

@nodejs-github-bot
Copy link
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 <[email protected]>
Reviewed-By: Geoffrey Booth <[email protected]>
Reviewed-By: Michaël Zasso <[email protected]>
Reviewed-By: Zeyu Yang <[email protected]>
@himself65
Copy link
Member

landed in cd4985c

@himself65 himself65 closed this May 21, 2020
codebytere pushed a commit that referenced this pull request Jun 18, 2020
PR-URL: #32202
Reviewed-By: Guy Bedford <[email protected]>
Reviewed-By: Geoffrey Booth <[email protected]>
Reviewed-By: Michaël Zasso <[email protected]>
Reviewed-By: Zeyu Yang <[email protected]>
@codebytere codebytere 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 <[email protected]>
Reviewed-By: Geoffrey Booth <[email protected]>
Reviewed-By: Michaël Zasso <[email protected]>
Reviewed-By: Zeyu Yang <[email protected]>
@codebytere codebytere mentioned this pull request Jul 13, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
esm Issues and PRs related to the ECMAScript Modules implementation.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants