`this` isn’t passed into async methods

[thorn0]

Describe the bug

This might be pretty niche, but I need to always have access to this inside my custom _async_to_generator. In the project I'm working on, methods of different objects use different promise implementations, so I'm doing something like const Promise = this.Promise || globalThis.Promise in _async_to_generator. However, this doesn't work because this isn’t passed into async methods.

I wanted to find another reason to question the current behavior, so I came up with this example using eval.

Input code

class Foo {
    async bar() {
        eval('console.log(this)');
    }
}

Config

{
  "jsc": {
    "parser": {
      "syntax": "ecmascript",
      "jsx": false
    },
    "target": "es2015",
    "loose": false,
    "minify": {
      "compress": false,
      "mangle": false
    }
  },
  "module": {
    "type": "es6"
  },
  "minify": false,
  "isModule": true
}

Link to the code that reproduces this issue

https://play.swc.rs/?version=1.11.21&code=H4sIAAAAAAAAA0vOSSwuVnDLz1eo5uVSAILE4sq8ZIWkxCINTZgQCKSWJeZoqCfn5xXn56Tq5eSna5RkZBZrqmtaQ9TU8nIBEQDs35CqTgAAAA%3D%3D&config=H4sIAAAAAAAAA1VPOw6DMAzdc4rIc4e2Ujv0Dj1ElBoUlJ9iIxUh7k4ICS2b38%2FPnoWUMJCGl5zzmEFUiTAdODM0eVbfzABqp0gnExkuTR1okzplCQu17AqwSj1ySdH9envUBNgQCFuics54003%2FnTq4mJDobNysyvcWz42itoILn7GI9ReeIu4XPOFnamXHYjD0bklOI4plBQmBQtEXAQAA

SWC Info output

No response

Expected behavior

this should be correctly set in async methods.

Actual behavior

this isn't passed.

Version

1.11.21

Additional context

Noticed also another bug with eval.

[magic-akari]

Regarding eval-related analysis: Our static analysis does not examine code within eval statements, making this references in such contexts undetectable. This behavior aligns with Babel's handling of similar cases, as demonstrated in this Babel REPL example.

For async functions: We carefully check if this is actually used in the code. If we always passed this blindly, it could cause errors in specific situations – like trying to access this before the super() call in a class constructor. That's why our compiler automatically removes unnecessary this references when they're not found in the original code.

Consider this example:

new class Foo extends class { }{
    constructor() {
        (async () => { })();
        super();
    }
}

In the original code, the async arrow function contains no this references. Automatic this injection during transpilation would violate JavaScript's specification by attempting to access this prior to the super() call, resulting in a ReferenceError.

Maybe related: evanw/esbuild#4141

---

Regarding your custom _async_to_generator implementation: The this value in transformed async functions might behave unexpectedly – it could point to a class instance, undefined (in strict mode), or other values. Since your code references globalThis, we suspect you actually intend to use the global object here. For such cases, we recommend either:

1. Directly using globalThis instead of the original this binding, or
2. Adopting the robust globalThis polyfill approach from core-js (see core-js globalThis implementation)

This avoids the ambiguity of dynamic this resolution while ensuring consistent global context access.

[thorn0]

we suspect you actually intend to use the global object here

No, globalThis.Promise is a fallback used when the class instance doesn't have the Promise property.

[thorn0]

Thanks for the detailed reply — that makes sense.

About the constructor example: if this-related issues only show up in such specific contexts, maybe that’s exactly where the guardrails should kick in.

In most other cases, it seems reasonable to preserve this even if it seems unused — just to avoid breaking code with eval and custom helpers like mine that rely on this being available. Always stripping it out feels a bit too aggressive when the cost of keeping it is low.

Not saying it should always be passed blindly — just that skipping it only when necessary might be a more robust middle ground.

I realize pretty well that juggling with custom promise implementations (AngularJS 1.x in my case, trying to migrate it to rspack) feels today like a thing of the past. But so does downlevelling to ES2015 overall, doesn’t it? So my humble suggestion is: if the compiler still supports legacy targets, it might as well avoid breaking patterns that are used in legacy codebases. Let’s keep the functionality that makes those projects maintainable.

[magic-akari]

For non-standard implementations and customization needs, there's a universal solution: implement your own SWC plugin. The plugin logic would mirror SWC's built-in transpilation logic exactly - you can refer to the implementation in this file:
crates/swc_ecma_compat_es2017/src/async_to_generator.rs

The main logic requiring modification can be found here:

swc/crates/swc_ecma_compat_es2017/src/async_to_generator.rs

Lines 426 to 439 in b4b3aff

	if fn_state.use_arguments {
	// fn.apply(this, arguments)
	call_async
	.make_member(quote_ident!("apply"))
	.as_call(DUMMY_SP, vec![this.as_arg(), arguments.as_arg()])
	} else if fn_state.use_this {
	// fn.call(this)
	call_async
	.make_member(quote_ident!("call"))
	.as_call(DUMMY_SP, vec![this.as_arg()])
	} else {
	// fn()
	call_async.as_call(DUMMY_SP, vec![])
	}

Your primary adjustment would be to make it consistently return the .apply form. Don't hesitate to ask if you need any assistance with the implementation.

[swc-bot]

This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.