Expose a prefix that plugins can use to annotate labelled statements and directives so they will be stripped out.

[loganfsmyth]

Q	A
Fixed Issues?
Patch: Bug Fix?	N
Major: Breaking Change?	N
Minor: New Feature?	Y
Tests Added + Pass?	Yes
Documentation PR
Any Dependency Changes?
License	MIT

Posting for thoughts. This idea popped into my head a while back and I'm curious what people think about it.

We have this problem where sometimes plugins will flag nodes with either random properties, or Symbols, or store them in WeakSets. I think that's a great approach when you are confident that the node won't be duplicated later, like if you are in direct control of a subtraversal and no other plugins can get in your way. On the other hand, it's entirely possible for unrelated plugins to copy or replace a node for one reason or another, and often this will clear random flags on the node.

This PR makes Babel automatically strip out directives like:

"BABEL_PREFIX_some whatever";

and whole labeled statements like

BABEL_PREFIX_whatever: {
  // a normal JS block
}

I'm proposing this PR because it seems like it could be kind of handy for us. It would be relatively straightforward to inject directives that contain metadata about a given block. The labeled statements I could also see, though they are probably harder to manage. On the other hand since they allow actually non-string content, they can interact with other transforms.

Essentially it exposes a prefix field on the plugin API object that can be used inside directive literals or inside the labels of labeled statements to make them be deleted at the end of Babel's transformation phase. We could for instance use this approach to mark each of Babel's helper functions with a directive, so they are easier to pick out when transforming a given file. It could also be useful as a way of injecting metadata about a function's bindings or something.

Thoughts?

[babel-bot]

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

[babel-bot]

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

[mAAdhaTTah]

This might solve the precendence issue we're seeing in #7154; we could use this to label await expressions that have been transformed into yield for the pipeline operator.

[loganfsmyth]

Good question. I haven't looked closely at that discussion before. You can't label expressions, so I don't know that it would be as simple as your description, but it might still be helpful. Hard to say.

[mAAdhaTTah]

Would this work?

co(function* foo () {
  "BABEL_PREFIX_await_transformed"
  const bar = yield baz;
})

[loganfsmyth]

That'd be stripped out, but I'm not sure it would be enough information for that other plugin to work. It needs to know specifically which yield statements used to be await statements. Assuming all yields inside a function with that directive were previously await will fail for async generator functions since they use both yield and await in the same function.

My preference would be something like #7154 (comment) for that issue.

[mAAdhaTTah]

@loganfsmyth In the above, my assumption was that statement would be injected above every transpiled instance. So it wouldn't apply to the whole block, just the next line, but maybe that's not the intention of this PR?

Plugin ordering seemed like a much stickier problem than using something like this to flag individual lines, and I was hoping to push along that PR.

[loganfsmyth]

This PR only removes directives, which are strings at the start of a function, so it would not apply to general standalone strings between statements.

using something like this to flag individual lines

Flagging individual lines is too granular unfortunately. You could certainly see someone doing

async function * fn() {
  var foo = await yield 42;
}

in the same statement.

Plugin ordering seemed like a much stickier problem

No argument there, but it's already a problem we have to deal with, and at least in this specific case it seems like we can pretty reasonably throw a clear error to let users know when they get the ordering wrong.

[mAAdhaTTah]

Is that legal syntax? I can't get it to parse in the repl. I get unexpected token errors when turning on proposal-async-generators. (As an aside, it doesn't appear the repl shows you a list of the currently enabled plugins.)

Flagging individual lines is too granular unfortunately.

I'm assuming you mean not granular enough :). If flagging individual lines is enough, are you open to stripping directives throughout a block to provide this as a potential solution to that problem or is that just a no-go for you?

[loganfsmyth]

Is that legal syntax? I can't get it to parse in the repl.

Ah woops, it needs parens: await (yield 42)

is that just a no-go for you?

I'd rather not add more complexity to work around plugin ordering issues, unless there's literally no way to achieve what we want, and I'm not convinced that is the case here.

[hzoo]

Should ping some people that have had to do this before

[loganfsmyth]

I'm gonna close this for now. It's not clear that it's the right approach, and it's a performance hit we may or may not want to take.