Add support for the updated import attributes proposal

[nicolo-ribaudo]

Q	A
Fixed Issues?
Patch: Bug Fix?
Major: Breaking Change?
Minor: New Feature?
Tests Added + Pass?	Yes
Documentation PR Link	babel/website#2780
Any Dependency Changes?
License	MIT

https://github.com/tc39/proposal-import-attributes

The changes compared to the import assertions proposals are listed at tc39/proposal-import-attributes#131

To make the migration easier, since import assertions are already widely used in tools:

• the old importAssertions parser plugin accepts the new with syntax by default
• the new importAttributes parser plugin has a deprecatedAssertSyntax option to accept the old syntax

In Babel 8, we will remove both the importAssertions plugin and the super old moduleAttributes plugin (which used the with keyword, but without braces). I will add the proper process.env.BABEL_8_BREAKING checks in a future cleanup PR.

Description generated by Copilot 🤖:

🤖 Generated by Copilot at d46267b

Summary

🆕🛠️🚧

This pull request adds support for the importAttributes plugin in the parser and the generator, and updates the code and tests to handle the new and legacy syntaxes for module attributes and assertions. It also renames the importAssertions plugin to importAttributes and adds a deprecation warning for the old name. It fixes some bugs and improves the error messages and the test output format for the related features.

Sing, O Muse, of the mighty pull request
That brought new features to the Babel code,
The importAttributes plugin, best
Of all the tools that parse the module node.

Walkthrough

• Rename importAssertions plugin to importAttributes and update syntax to match proposal (link, link, link, link, link, link)
• Add support for both with and assert keywords and both legacy and new module attribute syntaxes in importAttributes plugin (link, link, link, link, link)
• Update babel-generator to handle both attributes and assertions properties on import and export nodes and use _printAttributes function (link, link, link, link)
• Add error message for deprecated assert keyword in import attributes (link, link)
• Update ExportNamedDeclaration and ImportDeclaration functions to use maybeParseImportAttributes function and remove unused functions (link, link)
• Add test cases for importAttributes plugin with with keyword and deprecatedAssertSyntax option (link, link, link)
• Add test cases for importAssertions plugin with assert keyword (link, link, link)
• Add test case for experimental syntax without any plugin enabled (link, link)
• Add test case for importAssertions plugin with with keyword in dynamic import (link)
• Update test output for estree plugin with import assertions and attributes (link, link, link)
• Update test options for experimental syntax without any plugin enabled (link)
• Delete test files for deprecated moduleAttributes plugin (link, link)

[babel-bot]

Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/54409/

[JLHwung]

The current spec disallows such case: https://tc39.es/proposal-import-attributes/#prod-ImportDeclaration

[nicolo-ribaudo]

It's mostly an oversight; the plan is to update the proposal to allow it (tc39/proposal-import-attributes#136)

[JLHwung]

Can we introduce a new generator option

importAttributesVersion: "2023-03" | "2020-09" | "2020-06"

The default is "2023-03". So we can handle the AST collision between import attributes and the legacy module attributes proposal. Then syntax plugins can configure it accordingly.

The pros are:

• Sigil configs are decoupled from the AST, so we don't have to plug in more private-like node.extra.* properties
• Users don't need to write a dedicate codemod to migrate syntaxes (by manipulating node.extra.* properties)
• The output style is controlled in generator option instead of a parser plugin option, e.g. importAttributesVersion: "2020-09" can be used for Node.js 17.1.0 compatibility, though we will eventually materialize that option after import attributes gets spec'd.

The cons:
For users using the babel-plugin-syntax-module-attributes in the small time frame 2020-06 to 2020-09 (prior to renaming module-attributes to import-assertions), upgrading to Babel 7.22 will be breaking, unless they configured importAttributesVersion: "2020-06" or accept the new syntax. But we never heard any feedback about babel-plugin-syntax-module-attributes when renaming to syntax-import-assertions so I doubt it will break anyone.

[nicolo-ribaudo]

Sounds like a good plan to me 👍
I'm not particularly worried about people using the old "module attributes" syntax, given that the syntax plugin has virtually 0 downloads (https://www.npmjs.com/package/@babel/plugin-syntax-module-attributes) and it has been deprecated for years.

However, I would prefer to use "with", "assert", "with-legacy" as the version names. I know that we usually use year/month numbers, but in this case:

• the proposal is at stage 3, and it's very unlikely that the syntax will change again given that browsers are pushing to release
• most people will think about this in terms of "with vs assert"

[nicolo-ribaudo]

I managed to make it non-breaking also for users of the legacy syntax.

• By default, if the AST has .assertions we print assert
• By default, if the AST has .attributes we print the legacy with syntax (without braces)

A generator option importAttributesKeyword: "with" | "assert" | "with-legacy" can control the output format. @babel/plugin-syntax-import-attributes will automatically set importAttributesKeyword to "with", unless it has been explicitly set to something else.

If the AST has .attributes (thus if using importAttributes, moduleAttributes, or importAssertions with the with keyword) and importAttributesKeyword is not specified, @babel/generator will warn asking to explicitly set the option.

[JLHwung]

We should also handle the plugin assertions in expression.js#finishCallExpression

[JLHwung]

Nit, we can avoid the type cast:

attrs.push(this.finishNode(node, "ImportAttribute"));

[JLHwung]

Should also update how we calculate the maxArgumentCount.

[nicolo-ribaudo]

@JLHwung I don't know how I could forget to go through all the hasPlugin("importAssertions") calls to add the hasPlugin("importAttributes") variants where it makes sense 😅 I have done that now.

[liuxingbaoyu]

Can we use deprecationWarning or warn once globally?
Otherwise I'm worried that it will generate a lot of duplicate warnings when the user is used in many files.

This way we might also be able to remove auto-legacy.

[liuxingbaoyu]

Can we have importAttributesKeyword, assertions, attributes as variables?

[liuxingbaoyu]

I like IS_PUBLISH, thanks!

[nicolo-ribaudo]

I'm merging this PR into a feat-7.22.0/imports branch, since there are different PRs related to changes in import statements.