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

Open in StackBlitz

commit: abb2a7a

I think it is worthy of change as the JSON file frees us from manually copy-pasting JS source codes.

Shouldn't it the same if we generate a js/ts file that only export a string?

Update: Like this fisker@afa88d7

I think it is worthy of change as the JSON file frees us from manually copy-pasting JS source codes.

Shouldn't it the same if we generate a js/ts file that only export a string?

Update: Like this fisker@afa88d7

Thank you. I tried on this branch, we have a Babel plugin to rewrite imports from data/index.ts to data/index.js, which will not be resolvable because we typically do not compile data/*.ts files to data/*.js files.

Now that Babel 8 requires Node.js >= 22.18 which comes with ICU 77.1 supporting Unicode 16, if we want to shrink the size of this big regex which is also rarely used. A potential approach is to replace it with the following format

new RegExp (
  "[\\p{Identifier_Start}<code points assigned Identifier_Start in Unicode 17.0+>]",
  "u"
)

The new format will not contain double-digit hex points in practical because anything < 256 is well-defined and stable prior to Unicode 16.

It should drastically reduce the regex size while maintaining conformance to the latest Unicode standard. The downsize of this approach is that if you run Babel parser in a Node.js --without-intl build with the non-ASCII identifier, the parser will fail because Node.js does not have the required ICU data to evaluate \p{Identifier_Start}. Note that as of now ESLint also does not work on such Node.js build either.

The downsize of this approach is that if you run Babel parser in a Node.js --without-intl build with the non-ASCII identifier, the parser will fail because Node.js does not have the required ICU data to evaluate \p{Identifier_Start}.

I would be fine with this. For @babel/standalone we would transpile \p{Identifier_Start} away, right?

The downsize of this approach is that if you run Babel parser in a Node.js --without-intl build with the non-ASCII identifier, the parser will fail because Node.js does not have the required ICU data to evaluate \p{Identifier_Start}.

I would be fine with this. For @babel/standalone we would transpile \p{Identifier_Start} away, right?

Good question, yes and ideally the transpiled result should be as same as the transpiled result of the \p{Identifier_Start} itself, but I will need to test and confirm that. Note that the transpiled result will be longer than the current regex because the current regex contains only BMP characters and the other characters are handled in the linear search.

I'm concerned that when Unicode 18 is introduced, the parser will behave inconsistently across different engine versions.

I'm concerned that when Unicode 18 is introduced, the parser will behave inconsistently across different engine versions.

To clarify, what I mean in

new RegExp (
  "[\\p{Identifier_Start}<code points assigned Identifier_Start in Unicode 17.0+>]",
  "u"
)

is \p{Identifier_Start} and any other code points assigned Identifier_Start in Unicode 17 and above. Sorry that the + is a bit confusing in the regex context.

The downsize of this approach is that if you run Babel parser in a Node.js --without-intl build with the non-ASCII identifier, the parser will fail because Node.js does not have the required ICU data to evaluate \p{Identifier_Start}.

I would be fine with this. For @babel/standalone we would transpile \p{Identifier_Start} away, right?

Good question, yes and ideally the transpiled result should be as same as the transpiled result of the \p{Identifier_Start} itself, but I will need to test and confirm that. Note that the transpiled result will be longer than the current regex because the current regex contains only BMP characters and the other characters are handled in the linear search.

To keep this PR focused, I will keep this PR as-is and experiment a bit and open a new PR if this approach is applicable.

I'm finishing the preset-modules update, then let's release.