-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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: drop support for import assertions #52104
Conversation
Review requested:
|
Worth noting that v18.x does not support |
As I mentioned in #51622 (comment) I'm open to landing #51136 on v18.x. |
|
||
await rejects( | ||
import(`data:text/javascript,import${JSON.stringify(jsonModuleDataUrl)}assert{type:"json"}`), | ||
SyntaxError |
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.
This currently throws "unexpected token 'assert" -- I submitted a patch to V8 to make the error explicitly recommend to use 'with' instead: https://chromium-review.googlesource.com/c/v8/v8/+/5376260
This patch removes support for the `assert` keyword for import attributes. It was an old variant of the proposal that was only shipped in V8 and no other engine, and that has then been replaced by the `with` keyword. Chrome is planning to remove support for `assert` in version 126, which will be released in June. Node.js already supports the `with` keyword for import attributes, and this patch does not change that.
462d735
to
4c227bd
Compare
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.
lgtm
Since V8 will remove assert and it’s stage 3 going back to stage 2 and then broken in the spec anyway, is it semver major?(To me it looks more like experimental features and not subject to semver and @aduh95 also said something similar in #52104 (comment) ). It would not be great to continue having assert lingering around in v22 and then V8 breaks it and we cannot upgrade V8 on v22. If it’s semver-major we should try getting it into v22 in time. Otherwise we can land it later on v22 (still nicer to have it in the beginning but I guess it’s not the end of the world to land it in 22.1.0 or something). cc @targos @nodejs/releasers |
The CI failures don't seem related to my changes, but maybe I should try rebasing? Or could somebody re-trigger CI? The arm build is failing both on windows and OSX. For the test failures on Linux, one is a timeout and the other one is marked as flaky. |
@RafaelGSS this should be in v22 |
Now the macOS failure is a flaky test ( The failure on linux is a timeout:
(out of curiosity, when you have to re-run CI due to flaky tests, do you re-run everything or just the failed jobs?) |
When we use the "Resume build" button on Jenkins, it reruns all jobs that are either orange (only flaky failures) or red (at least one non-flaky failure). |
@targos it does not seem I can rerun the GHA. |
It's probably too old to be re-runnable. |
Should I push an empty commit to retrigger it? |
let's see if the main CI passes first. |
Please push a fresh commit. |
The
notable-change
Please suggest a text for the release notes if you'd like to include a more detailed summary, then proceed to update the PR description with the text or a link to the notable change suggested text comment. Otherwise, the commit will be placed in the Other Notable Changes section. |
Drop support for import assertionsThe old import assertions proposal has been replaced by "import attributes": to migrate to the new proposal you can replace the For example, import "foo" assert { ... } should be replaced with import "foo" with { ... } |
This patch removes support for the `assert` keyword for import attributes. It was an old variant of the proposal that was only shipped in V8 and no other engine, and that has then been replaced by the `with` keyword. Chrome is planning to remove support for `assert` in version 126, which will be released in June. Node.js already supports the `with` keyword for import attributes, and this patch does not change that. PR-URL: #52104 Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io> Reviewed-By: Ethan Arrowood <ethan@arrowood.dev> Reviewed-By: Geoffrey Booth <webadmin@geoffreybooth.com>
This comment was marked as spam.
This comment was marked as spam.
Replace keyword "assert" with "with" to support NodeJS v22+. Requires NodeJS v20.10+ or v18.20.x+ (LTS) PR that removes assert from NodeJS: nodejs/node#52104
Replace keyword "assert" with "with" to work with NodeJS v22+ Requires NodeJS v18.20.x+ (LTS) or v20.10+ NodeJS PR that removed the keyword: nodejs/node#52104
- remove single usage of import assertion (import ... with/assert) which was breaking compat with older node 18 versions (see https://github.com/nodejs/node/pull/52104\#issuecomment-2000337367)
- remove import `with` keyword, see #492. tried replacing with newer `assert` syntax but it was [breaking](nodejs/node#52104 (comment)) older node 18 versions. - upgrade azure package to support node v22 - bump packaged oclif node version to latest LTS (20.13.1) - bump node version for CI workflows to 20.x - keep supported version in package.json to >=18.0.0 --------- Co-authored-by: Roy Razon <roy@livecycle.io>
These no longer build in Node 22 since import assertions were removed: nodejs/node#52104
* fix syntax error due to `assert` nodejs/node#52104 (comment) * fix missed assert thanks for pointing it out puxlit * bump nodejs version and regenerate package-lock.json per kocka's request
Description for changelog: #52104 (comment)
This patch removes support for the
assert
keyword for import attributes. It was an old variant of the proposal that was only shipped in V8 and no otherengine, and that has then been replaced by the
with
keyword.Chrome is planning to remove support for
assert
in version 126, which will be released in June.
Node.js already supports the
with
keyword forimport attributes, and this patch does not change that.
Fixes #51622