False positive compilation with 'async' properties

[pjeby]

The current filtering regex is overly-optimistic; it should check for async function, not just the word async. With the current state of things, regenerator thinks e.g. its own runtime needs to be recompiled. ;-) (Due to an .async property.)

[benjamn]

Hmm, you have a point, but what do you think about async arrow functions? E.g., async (x, y) => x + await y.

[pjeby]

The real issue for me isn't that it does extra work parsing: it's that the returned source code string has changed, even when no actual code changes were made.

In regenerator-loader, I want to be able to tell whether regenerator really needed to change the code or not, in order to avoid corrupting the source maps on unchanged files.

For example, if you run a minimized version of jQuery through regenerator, it doesn't actually change the code, but the code comes back out with extra parentheses, breaking the existing source map. (A stricter regex is in effect just a workaround for this issue.)

So, if for example the object returned by regenerator.compile() had a flag for whether any semantic changes were made, I could use that instead of comparing the input source text and output source text, as I am doing now.

[pjeby]

Per a suggestion from a user, it's occurred to me that if the output code doesn't reference regeneratorRuntime, then it doesn't need to require() the runtime. So I can work around the looseness of the current regex for that purpose.

At this point, I think I'm okay with filtering the false positives from the regenerator-loader side. I can make a regex that'll even match async arrow functions, it just won't be able to handle things like async /* wut? */ () => x, and I can document that limitation (which I think is acceptable given the use case). I can see why for regenerator, though, you'd want to err on the side of avoiding false negatives instead.

Still, it would be nice if regenerator output the original source when no actual generators or async functions were found during the parse. (Feel free to close this if you disagree.)

[ghost]

Thank you for reporting this issue and appreciate your patience. We've notified the core team for an update on this issue. We're looking for a response within the next 30 days or the issue may be closed.