esm: allow resolve to optionally return import assertions

[GeoffreyBooth]

As part of #44710@targos discovered that our test fixture loader for “assertionless” JSON imports—import data from './file.json' where there’s no assert{type: 'json' }—was only working because it mutated the context.importAssertions object, which doesn’t work on the “loaders off-thread” branch. But it arguably shouldn’t work on main 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 the resolve 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

[nodejs-github-bot]

Review requested:

• @nodejs/loaders
• @nodejs/modules

[nodejs-github-bot]

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

[nodejs-github-bot]

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

[targos]

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).

[GeoffreyBooth]

I’m not sure what you want changed, if anything?

[targos]

I don't know how to write it differently. If you think users can understand the current wording that's fine.

[aduh95]

The first word of the commit message should be an imperative verb:

node/doc/contributing/pull-requests.md

Lines 168 to 169 in 5af2021

	* be prefixed with the name of the changed [subsystem](#appendix-subsystems)
	and start with an imperative verb. Check the output of `git log --oneline

resolve is an imperative verb, but is not used as one here and it's quite confusing.

[bmeck]

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: ***@***.***>

[GeoffreyBooth]

Because resolution is explicitly banned from using import assertions to affect it in spec: import assertions (tc39.es)

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.

[nodejs-github-bot]

Landed in 91ca2d4

[RafaelGSS]

Hi @GeoffreyBooth! This didn't land cleanly on v19.x-staging, can you create a manual backport? Thanks

[GeoffreyBooth]

@RafaelGSS This needs to wait on #45869 (comment).

[juanarbol]

Hey, this is not landing cleanly on v18.x line :(

[GeoffreyBooth]

Hey, this is not landing cleanly on v18.x line :(

What if you land #43772 and then #45869? Hopefully this can land cleanly after those two go first?

[targos]

Lands cleanly indeed.

[ljharb]

Given the tenuous status of import assertions, should this change be backported?