Fix due to this plugin transforming the async method and async arrow function, it caused arguments no longer point the original function.
For example:
Before
```js
class Cls {
async method() {
() => {
console.log(arguments)
}
}
}
```
After:
```js
class Cls {
method() {
var _arguments = arguments;
return babelHelpers.asyncToGenerator(function* () {
() => {
console.log(_arguments);
};
})();
}
}
```
In this way, the `_arguments` is its original function's arguments
### For performance regression
It seems we need to check the IdentifierReference and BindingIdentifier if it's an `arguments`, that causes a significant regression, we may need a cheap way to do checking
After transformation, super expressions have moved to unexpected places. This PR replaces super expression to call expression, and then inserts the super methods to the top of the method body.
For example:
Before:
```js
class G {
async method() {
super.foo()
}
}
```
After:
```js
class G {
method() {
var _superprop_getFoo = () => super.foo,
_this = this;
return _asyncToGenerator(function* () {
_superprop_getFoo().call(_this);
})();
}
}```
Support for inferring function name from ObjectPropertyValue's key
For example:
```js
({ foo: async function() {} })
```
After this, we will able to infer `foo` for the object method
In this PR, most of the async functions have transformed correctly. But the async arrow functions don't fully transform correctly yet, it is related to we need to transform the arrow function to the generator function. For example:
Input:
```js
function declaration() {
const asy = async () => {
console.log(this.name)
}
}
```
Output:
```js
function declaration() {
const asy = babelHelpers.asyncToGenerator(function* () {
console.log(this.name);
});
}
```
Expected Output:
```js
function declaration() {
var _this = this;
const asy = /*#__PURE__*/function () {
var _ref = babelHelpers.asyncToGenerator(function* () {
console.log(_this.name);
});
return function asy() {
return _ref.apply(this, arguments);
};
}();
}
```
From the expected output, we haven't handled `this` correctly, which means even if the `arrow-function` plugin doesn't enable, we still need to handle this correctly as the `arrow-function` plugin does, and further question if `arrow-function` plugin is enabled, how to avoid these making conflict?
I thought we may move out the implementation of `arrow-function` and as a common helper, this way every plugin can handle this well
Make naming of temp vars follow Babel. It wasn't apparent that our version of this transform was behaving differently from Babel because the Babel plugin has very few tests. The added tests replicate Babel's output.
Fix exponentiation operator transform to bail out early if a private class property.
We can't transform this:
```js
class C {
#p;
method() {
this.#p **= 2;
}
}
```
But we should at least leave it alone. Previously `get_obj_ref` called `ast.move_expression(expr)` on the member expression's object before bailing out, so example above was transformed to:
```js
class C {
#p;
method() {
null.#p **= 2; // <-- `null`
}
}
```
This PR makes it spot this case early and bail out *before* calling `ast.move_expression(expr)`.
Fix JSX source transform when run alone without main JSX transform.
The added test case is same as one of Babel's exec test cases, but the exec test fails due to `transformAsync` not being present.
Currently whether conformance fixture files have trailing line breaks is inconsistent - some have them, some don't. Make all of them have a trailing line break.
Rename transform conformance RegExp test fixtures folder from "esbuild-tests" to "regexp", to reflect that not all these tests are copied from ESBuild.
related: #4754
The implementation port from [esbuild](332727499e/internal/js_parser/js_parser.go (L12820-L12840)). 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
