[v20.x backport] esm: use import attributes instead of import assertions #50183
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
PR-URL: nodejs#49523 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Yagiz Nizipli <[email protected]>
PR-URL: nodejs#49887 Fixes: nodejs#49724 Reviewed-By: Geoffrey Booth <[email protected]> Reviewed-By: LiviaMedeiros <[email protected]> Reviewed-By: Jacob Smith <[email protected]> Reviewed-By: Chemi Atlow <[email protected]>
|
Review requested:
|
nodejs-github-bot
added
lib / src
aduh95
force-pushed
the
esm-import-attributes-v20
branch
2 times, most recently
from
d9602c7
to
7ae7c89
Compare
GeoffreyBooth
added
the
commit-queue-rebase
aduh95
force-pushed
the
esm-import-attributes-v20
branch
from
7ae7c89
to
6eed46c
Compare
|
@nodejs/v8 I would love if I could get a review of 17ab6e9 – I don't expect it to be dangerous, but since 20.x is about to be LTS I'd rather have a few extra pairs of eyes on it. |
GeoffreyBooth
approved these changes
Oct 24, 2023
|
Looking at https://bugs.chromium.org/p/v8/issues/detail?id=13856:
|
Original commit message:
[import-attributes] Implement import attributes, with `assert` fallback
In the past six months, the old import assertions proposal has been
renamed to "import attributes" with the follwing major changes:
1. the keyword is now `with` instead of `assert`
2. unknown assertions cause an error rather than being ignored
To preserve backward compatibility with existing applications that use
`assert`, implementations _can_ keep it around as a fallback for both
the static and dynamic forms.
Additionally, the proposal has some minor changes that came up during
the stage 3 reviews:
3. dynamic import first reads all the attributes, and then verifies
that they are all strings
4. there is no need for a `[no LineTerminator here]` restriction before
the `with` keyword
5. static import syntax allows any `LiteralPropertyName` as attribute
keys, to align with every other syntax using key-value pairs
The new syntax is enabled by a new `--harmony-import-attributes` flag,
disabled by default. However, the new behavioral changes also apply to
the old syntax that is under the `--harmony-import-assertions` flag.
This patch does implements (1), (3), (4) and (5). Handling of unknown
import assertions was not implemented directly in V8, but delegated
to embedders. As such, it will be implemented separately in d8 and
Chromium.
To simplify the review, this patch doesn't migrate usage of the term
"assertions" to "attributes". There are many variables and internal
functions that could be easily renamed as soon as this patch landes.
There is one usage in the public API
(`ModuleRequest::GetImportAssertions`) that will probably need to be
aliased and then removed following the same process as for other API
breaking changes.
Bug: v8:13856
Change-Id: I78b167348d898887332c5ca7468bc5d58cd9b1ca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4632799
Commit-Queue: Shu-yu Guo <[email protected]>
Reviewed-by: Adam Klein <[email protected]>
Cr-Commit-Position: refs/heads/main@{#89110}
Refs: v8/v8@159c82c
Refs: v8/v8@a0fd320
Original commit message:
[import-attributes] Remove support for numeric keys
During the 2023-09 TC39 meeting the proposal has been updated to remove support
for bigint and float literals as import attribute keys, due to implementation
difficulties in other engines and minimal added value for JS developers.
GH issue: tc39/proposal-import-attributes#145
Bug: v8:13856
Change-Id: I0ede2bb10d6ca338a4b0870a1261ccbcd088c16f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4899760
Reviewed-by: Shu-yu Guo <[email protected]>
Commit-Queue: Joyee Cheung <[email protected]>
Cr-Commit-Position: refs/heads/main@{#90318}
Refs: v8/v8@ea996ad
The old import assertions proposal has been renamed to "import attributes" with the follwing major changes: 1. The keyword is now `with` instead of `assert`. 2. Unknown assertions cause an error rather than being ignored, This commit updates the documentation to encourage folks to use the new syntax, and add aliases for module customization hooks. PR-URL: nodejs#50140 Fixes: nodejs#50134 Refs: v8/v8@159c82c Reviewed-By: Geoffrey Booth <[email protected]> Reviewed-By: Jacob Smith <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]>
The old import assertions proposal has been renamed to "import attributes" with the following major changes: 1. The keyword is now `with` instead of `assert`. 2. Unknown assertions cause an error rather than being ignored. This PR updates the documentation to encourage folks to use the new syntax, and add aliases to preserve backward compatibility. PR-URL: nodejs#50141 Reviewed-By: Geoffrey Booth <[email protected]> Reviewed-By: Vinícius Lourenço Claro Cardoso <[email protected]>
aduh95
force-pushed
the
esm-import-attributes-v20
branch
from
ca46047
to
edc1c4e
Compare
Thanks for the pointer! IIUC d22b640 already implements all the relevant changes. |
|
Landed in 27e957c...57efd52 |
targos
pushed a commit
that referenced
this pull request
Nov 11, 2023
Original commit message:
[import-attributes] Implement import attributes, with `assert` fallback
In the past six months, the old import assertions proposal has been
renamed to "import attributes" with the follwing major changes:
1. the keyword is now `with` instead of `assert`
2. unknown assertions cause an error rather than being ignored
To preserve backward compatibility with existing applications that use
`assert`, implementations _can_ keep it around as a fallback for both
the static and dynamic forms.
Additionally, the proposal has some minor changes that came up during
the stage 3 reviews:
3. dynamic import first reads all the attributes, and then verifies
that they are all strings
4. there is no need for a `[no LineTerminator here]` restriction before
the `with` keyword
5. static import syntax allows any `LiteralPropertyName` as attribute
keys, to align with every other syntax using key-value pairs
The new syntax is enabled by a new `--harmony-import-attributes` flag,
disabled by default. However, the new behavioral changes also apply to
the old syntax that is under the `--harmony-import-assertions` flag.
This patch does implements (1), (3), (4) and (5). Handling of unknown
import assertions was not implemented directly in V8, but delegated
to embedders. As such, it will be implemented separately in d8 and
Chromium.
To simplify the review, this patch doesn't migrate usage of the term
"assertions" to "attributes". There are many variables and internal
functions that could be easily renamed as soon as this patch landes.
There is one usage in the public API
(`ModuleRequest::GetImportAssertions`) that will probably need to be
aliased and then removed following the same process as for other API
breaking changes.
Bug: v8:13856
Change-Id: I78b167348d898887332c5ca7468bc5d58cd9b1ca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4632799
Commit-Queue: Shu-yu Guo <[email protected]>
Reviewed-by: Adam Klein <[email protected]>
Cr-Commit-Position: refs/heads/main@{#89110}
Refs: v8/v8@159c82c
Refs: v8/v8@a0fd320
PR-URL: #50183
Reviewed-By: Geoffrey Booth <[email protected]>
targos
pushed a commit
that referenced
this pull request
Nov 11, 2023
Original commit message:
[import-attributes] Remove support for numeric keys
During the 2023-09 TC39 meeting the proposal has been updated to remove support
for bigint and float literals as import attribute keys, due to implementation
difficulties in other engines and minimal added value for JS developers.
GH issue: tc39/proposal-import-attributes#145
Bug: v8:13856
Change-Id: I0ede2bb10d6ca338a4b0870a1261ccbcd088c16f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4899760
Reviewed-by: Shu-yu Guo <[email protected]>
Commit-Queue: Joyee Cheung <[email protected]>
Cr-Commit-Position: refs/heads/main@{#90318}
Refs: v8/v8@ea996ad
PR-URL: #50183
Reviewed-By: Geoffrey Booth <[email protected]>
This was referenced Nov 12, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Backport of #50140
Because the version of V8 does not supportActually, the V8 changes were not too difficult to backport, so I decided to do that. That way,withkeyword, I have not ported the changes in the tests and the docs are still usingassert.withkeyword will be supported on all non-EOL as soon as v18.x reaches EOL.To avoid conflicts, I'm also backporting: