Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/58824

I'm a bit hesitant to add a template option, because of #9975.
Otherwise we'll just have to add a ton of options.

Would you prefer to add allowYieldOutsideFunction and allowPrivateNameOutSideClass or add a template?

I prefer the specific option flag. The template option seems like the loose option of other Babel plugins that we have tried to get rid of in the favor of assumptions.

Unlike allowReturnOutsideFunctino, both allowAwaitOutsideFunction and allowYieldOutsideFunction potentially parse the same snippet into different AST: e.g. await [foo] can be either an AwaitExpression or a MemberExpression. Though we may speculate that the former is more desired, the template usage example for the latter might be a bit confusing:

// template option
require('babel-template')(`await [foo]`, { template: false })(foo: identifier("foo"))
// allowAwaitOutsideFunction option
require('babel-template')(`await [foo]`, { allowAwaitOutsideFunction: false })(foo: identifier("foo"))

And because of that, allowAwaitOutsideFunction may still have to interact with the template option: One may want top level yield but not top level await. Then we will have to define the precedence of template over specific options, which sounds like a deep rabbit hole for me.

The allowYieldOutsideFunction option seems potentially misleading. Based on the original issue, the core requirement appears to be enabling parser state management to simulate being within generator/async function contexts - rather than literally allowing yield/await outside functions.

Key observations:

1. yield expr parsing requires assuming generator function context.
2. await expr parsing needs async function context simulation (including TLA as pseudo-async).
3. Current examples like:

   function foo() { yield 1; }
   function bar() { await 2; }

   don't represent the intended use cases.

I suggest considering context simulation through parser state flags rather than literal "allow outside function" semantics. Would appreciate other perspectives on this interpretation.

@magic-akari
As I understand it the use case here is to allow the use of yield at the top level to support require('babel-template')('yield A').
allowYieldOutsideFunction only allows the use of yield at the top level.
function foo() { yield 1; } is still rejected.

@magic-akari I agree that the name is a bit unfortunate, ideally I would like some option like template/context that is context: { generator: boolean; async: boolean; function boolean; }. However, we already have allowReturnOutsideFunction/allowAwaitOutsideFunction/allowNewTargetOutsideFunction, and this option is just continuing that pattern.

Note that in your example the yield inside function foo() { yield 1; } is not outside of a function, thus not affected by the option :)

@liuxingbaoyu Could you prepare the docs PR?