feat(transformer): support all /regex/ to new RegExp transforms

[Dunqing]

related: #4754

The implementation port from esbuild. And cover all babel's regexp plugins

---

The following description was generated by Graphite 😋

TL;DR

Added support for transforming various RegExp features to ensure compatibility with older JavaScript environments.

What changed?

• Implemented a new RegExp transformer to handle unsupported RegExp literal features
• Added options to control different RegExp transformations (e.g., sticky flag, unicode flag, dot-all flag, etc.)
• Updated the transformer to convert unsupported RegExp literals into new RegExp() constructor calls
• Added test cases for different RegExp transformations
• Integrated the new RegExp transformer into the existing transformation pipeline

How to test?

1. Run the existing test suite to ensure no regressions
2. Execute the new RegExp-specific tests in the tasks/transform_conformance/tests/esbuild-tests/test/fixtures/regexp/ directory
3. Try transforming code with various RegExp features using different target environments to verify correct transformations

[graphite-app]

Your org has enabled the Graphite merge queue for merging into main

Add the label “merge” to the PR and Graphite will automatically add it to the merge queue when it’s ready to merge. Or use the label “hotfix” to add to the merge queue as a hot fix.

You must have a Graphite account and log in to Graphite in order to use the merge queue. Sign up using this link.

[Dunqing]

• refactor(transformer/react): move all entry points to implementation of Traverse trait #5473
• feat(transformer): support all /regex/ to new RegExp transforms #5387 👈
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @Dunqing and the rest of your teammates on Graphite

[codspeed-hq]

CodSpeed Performance Report

Merging #5387 will degrade performances by 13.86%

_{Comparing 09-01-feat_transformer_support_all_regexp_plugins (c59d8b3) with main (91b39c4)}

Summary

❌ 2 regressions
✅ 27 untouched benchmarks

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

	Benchmark	main	09-01-feat_transformer_support_all_regexp_plugins	Change
❌	transformer[antd.js]	27.7 ms	32.2 ms	-13.86%
❌	transformer[pdf.mjs]	10.2 ms	10.7 ms	-4.5%

[Dunqing]

I saw a 2% performance regression in enabling plugins.

[Boshen]

How are these turned on or off from targets?

[Dunqing]

How are these turned on or off from targets?

Consistent with other plugins, automatically enable plugins below those versions(from parsed targets). I don't know how to turn off plugins that are enabled by targets. Might want to look into how Babel does this

[Boshen]

LGTM, waiting for @overlookmotel to take a look.

[Dunqing]

I just found that RegExpPattern AST had merged into oxc. So this plugin doesn't need to roughly parse and check pattern anymore. That's so great! Thanks for your work! @rzvxa @leaysgur

[overlookmotel]

I've pushed a few commits. As usual, feel free to revert them if you don't like them.

Concerning changing "RegExp".into() to Atom::from("RegExp"): This makes no actual difference. It's just my personal preference to be explicit, as I find it makes it easier to read the code. Where I see .into() I often find myself wondering "but into what?". Atom::from(...) removes that ambiguity.

[Dunqing]

@rzvxa Can you take a look at the transform_conformance job? There is a panic in

oxc/crates/oxc_regular_expression/src/display.rs

Line 378 in 470a6e3

let ch = char::from_u32(cp).expect("Invalid `Character`!");

[Dunqing]

Well, parsing RegExp increases the performance regression from 6% to 13%.

[rzvxa]

@rzvxa Can you take a look at the transform_conformance job? There is a panic in

oxc/crates/oxc_regular_expression/src/display.rs

Line 378 in 470a6e3

let ch = char::from_u32(cp).expect("Invalid `Character`!");

Yes, I'll take a look. I'm having a hunch as to what it might be.

[leaysgur]

@rzvxa Issue is caused by these match cases and when ch is not used inside like UnicodeEscape. (Sorry my suggested code)

oxc/crates/oxc_regular_expression/src/display.rs

Line 379 in 470a6e3

let result = match this.kind {

These patterns were the issue.

if raw == r"/^|\udf06/ug"
  || raw == r"/\udf06/"
  || raw == r"/\udf06/u"
  || raw == r"/^|\udf06/g"

[rzvxa]

@leaysgur Yes, that was my theory as well. Thanks for getting to the bottom of this.

@Dunqing I've submitted a fix for it.

[Dunqing]

Ah, This PR was closed, and cannot reopen it 🥲

[Boshen]

@graphite-app graphite-app bot closed this in 9b984b3 16 minutes ago

wtf

[Boshen]

@Boshen Boshen reopened this now

It can only be reopened from graphite.

[graphite-app]

Merge activity

• Sep 5, 6:47 AM EDT: overlookmotel added this pull request to the Graphite merge queue.
• Sep 5, 7:08 AM EDT: overlookmotel merged this pull request with the Graphite merge queue.

[overlookmotel]

I didn't mean to add the merge label! I added it to upstack PR and didn't notice it would also merge this. Am reading through the updated code now.

[overlookmotel]

Well Graphite merged it anyway! I'll do some follow-up PRs.