-
Notifications
You must be signed in to change notification settings - Fork 30k
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: allow resolve
to optionally return import assertions
#46153
esm: allow resolve
to optionally return import assertions
#46153
Conversation
Review requested:
|
52f571c
to
c797d07
Compare
d34bf01
to
e80eaa6
Compare
e80eaa6
to
1a9e7d6
Compare
doc/api/esm.md
Outdated
Import assertions are part of the cache key for saving loaded modules into the | ||
Node.js internal module cache. The `resolve` hook is responsible for returning | ||
an `importAssertions` object if the module should be cached with different | ||
assertions than were present in the source code (for example, if no assertions | ||
were present but the module should be cached with assertions | ||
`{ type: 'json' }`). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like the key thing is an implementation detail. The reason a loader needs to customize import assertions is to support modules that import JSON without the assertion (bypass the validation).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I’m not sure what you want changed, if anything?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know how to write it differently. If you think users can understand the current wording that's fine.
resolve
to optionally return import assertions
The first word of the commit message should be an imperative verb: node/doc/contributing/pull-requests.md Lines 168 to 169 in 5af2021
|
1a9e7d6
to
0a01441
Compare
0a01441
to
246694f
Compare
246694f
to
c3a2e8b
Compare
e9822be
to
349d054
Compare
Because resolution is explicitly banned from using import assertions to
affect it in spec: import assertions (tc39.es)
<https://tc39.es/proposal-import-assertions/#sec-semantics>
- moduleRequest.[[Assertions]] must not influence the interpretation of
the module or the module specifier; instead, it may be used to determine
whether the algorithm completes normally or with an abrupt completion
<https://tc39.es/ecma262/#sec-completion-record-specification-type>.
…On Wed, Jan 11, 2023 at 8:49 AM Antoine du Hamel ***@***.***> wrote:
I've found traces in the codebase that this design was already
experimented with in the past:
https://github.com/nodejs/node/blob/611d5b46f8457df4c924c237bcaeb55ecf104116/test/fixtures/es-module-loaders/builtin-named-exports-loader.mjs#L23
I wonder why we moved away from it 🤔
—
Reply to this email directly, view it on GitHub
<#46153 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABZJI6IEWKVRI7ACOZTJSTWR3B53ANCNFSM6AAAAAATWCNIPA>
.
You are receiving this because you are on a team that was mentioned.Message
ID: ***@***.***>
|
Yes, but that wouldn’t apply to user loaders, which are allowed to violate spec. The reference @aduh95 found is in a user loader test fixture. |
This comment was marked as off-topic.
This comment was marked as off-topic.
Landed in 91ca2d4 |
Hi @GeoffreyBooth! This didn't land cleanly on v19.x-staging, can you create a manual backport? Thanks |
@RafaelGSS This needs to wait on #45869 (comment). |
Hey, this is not landing cleanly on v18.x line :( |
Lands cleanly indeed. |
PR-URL: #46153 Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Jacob Smith <[email protected]>
Given the tenuous status of import assertions, should this change be backported? |
PR-URL: #46153 Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Jacob Smith <[email protected]>
PR-URL: nodejs/node#46153 Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Jacob Smith <[email protected]>
PR-URL: nodejs/node#46153 Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Jacob Smith <[email protected]>
As part of #44710 @targos discovered that our test fixture loader for “assertionless” JSON imports—
import data from './file.json'
where there’s noassert { type: 'json' }
—was only working because it mutated thecontext.importAssertions
object, which doesn’t work on the “loaders off-thread” branch. But it arguably shouldn’t work onmain
either, as mutating function input is a poor way for a hook to return information.This PR adds an optional
importAssertions
property to the object returned by theresolve
hook, to enable the use case where a module is cached with different import assertions than were present in the original source. I think this is the “correct” way that user hooks should inform the internal module loader what assertion type to use as part of the module cache key, rather than relying on input mutation.cc @nodejs/loaders