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
Closes#6358
@preyneyv I know you've been working on this problem.
This is an implementation that has been dormant on my local for a while.
- All tests are passing
- However, the approach is simple but not general, so there might be some edge cases that were missed
- There's also room for improvement in terms of performance
For these reasons, it was marked as WIP for me.
I believe the test cases and other parts are usable, so feel free to fork and replace them with your implementation if you'd like.
> Closes#6750
Fixes a false positive in `react/iframe-missing-sandbox` on `document.createElement`, which is not react and has no way of passing a sandbox prop/attribute on creation.
- Added TypeScript annotation for `ParseResult.program`
- Modified the entrypoint for `oxc-parser` to allow wrapping the napi functions
- Updated `index.js` to parse the `program` string into a JSON object
- Updated tests
- Added a dependency on `@oxc/types`
This makes the use of `Address` an internal implementation detail of `StatementInjectorStore`. The caller shouldn't need to care about how `StatementInjectorStore` achieves its work. In future it might use `NodeId`, for instance.
We could broaden this in future so these methods take a `&A where A: GetAddress` if we need to, but for now taking a `&Statement` seems OK.
Follow-up after #6830.
Now that `generate_binding` doesn't need access to `AstBuilder`, it can move into `TraverseScoping`.
Occasionally this is helpful when you need to borrows 2 parts of `TraverseCtx` simultaneously. e.g.:
```rs
// This fails to compile because we try to mutably borrow `TraverseCtx`
// while it's already borrowed
if let Ancestor::ProgramBody(body) = ctx.parent() {
// ^^^ immutable borrow
let binding = ctx.generate_binding(name, scope_id, flags);
// ^^^ mutable borrow
}
// Borrow-checker allows this because we borrow fields of `TraverseCtx` separately
if let Ancestor::ProgramBody(body) = ctx.ancestry.parent() {
let binding = ctx.scoping.generate_binding(name, scope_id, flags);
}
```
Follow-up after #6805.
`TraverseCtx::generate_binding` take an `Atom` instead of a `CompactStr`. If it's an existing var name (which it must be, otherwise we'd be using `TraverseCtx::generate_uid`), an `Atom` will already exist in the arena for this symbol name, so we'd be better off reusing it, rather than writing the same `Atom` into the arena again.
In particular:
* the long comment was scrolling off side of screen on
[npm.com](https://www.npmjs.com/package/oxc-parser).
* the example is ESM, so can simplify it by using top level await.
These two APIs are used to create a symbol with the provided symbol name, The difference from `generate_uid` is that we don't need to create a unique name for the symbol.
If you have a better method name for this, Feel free to edit this PR directly
