Async generator generator polyfill causes crashes in older browsers

[tido64]

The async generator generator polyfill introduced 0.18.8 causes crashes in "older" browsers (such as Hermes) because it assumes that Symbol.asyncIterator exists:

esbuild/internal/runtime/runtime.go

Lines 392 to 393 in a7fcc43

	export var __yieldStar = value => {
	var obj = value[__knownSymbol('asyncIterator')]

We've worked around the crash by polyfilling the symbol, but it feels like I'm missing something. It works for now, but I don't know if this causes other issues or whether there's a proper solution.

[evanw]

I think this behavior with Symbol was originally from TypeScript's implementation of the using statement. There it makes sense that people would have to polyfill Symbol.dispose since any use of the using statement needs to use Symbol.dispose when constructing the object. But async generators are different because it's possible (and even likely) to use them without your code ever using Symbol.asyncIterator at all. So I think it makes sense for esbuild to polyfill Symbol.asyncIterator in this case.

[tido64]

Do you have a preference for how this should be done? I'd like to give it a shot if I have some time.

[jakebailey]

FWIW it was intentional on the TypeScript side to not use Symbol.for: microsoft/TypeScript#54505 (comment)

Babel uses a different symbol name for this (some @@ prefix), so I think code generated by Babel won't work with the new helper as it will try to use a different name (and vice versa), which is roughly the hazard mentioned in the linked comment. Seemingly the most compatible option is to polyfill the real global.

[jakebailey]

I misspoke; Babel uses the same string you have here. I guess this is only a hazard for compat with typescript code.