I'm against merging this into Babel until the proposal progresses further. I would like to see this end up in https://github.com/tc39/ecma262/blob/master/stage0.md first.

Until then, I'm happy to leave this one open.

@loganfsmyth Updated. Thanks for the code review :)

@hzoo Oh hmm, could you explain the relationship between plugins and babel's versioning?

@mindeavor Just to be clear, I don't support landing this PR until it has an official proposal, I just reviewed it so it's consistent if we di land it in the future.

To answer your question, all Babel 6 plugins in code and currently compiled using Babel 5, that means that they all depend on [email protected].

I haven't reviewed the code but this isn't going to be merged until it has a TC39 champion and has been or is going to be presented to the committee. If in the future there's no signs of the committee ever accepting this then it'll be closed. Nonetheless, thanks for doing this! Just wanted to be explicit so there's no surprises down the line.

Understandable. For the record, is it accurate to say there is no way for others to try out the proposal other than forking babel or using / writing another transpiler?

You can publish the plugins standalone on npm but would also need to publish a new babylon version for the parser changes

Has there been any progress in getting a TC39 champion? If not this will be closed.

I'm curious, did TC39 members turn out reluctant or was there no good place to pitch them ideas?

Edit: I just realized there is esdiscuss, though I haven't seen a corresponding thread on there. Had you considered this, @mindeavor?

Hi @kittens, I totally understand why you dont want to merge this PR but at the very least, I believe it's reasonable to ask that the parser should be enhanced so that both |> and <| can be matched and used by any plugin.

If anything, Babel should help people be creative and experiment ideas...

@tlvenn you can feel free to discuss the left-facing operator at tc39/proposal-pipeline-operator#3 - I personally don't feel it's necessary, but that's no reason not to make an argument for it.

Hi @TehShrike, I am not trying to debate here on the semantic of what that operator should or should not do, I am just trying to argue that Babel should let people use it, the way they want, if they wish to. And by using it, I mean developing a plugin that would match on that operator and do something.

Just for reference, right now, people end up overloading existing operators such as | and >> which is far from ideal.

Going to close for now, (also babylon moved out to another repo in the meantime)

@tlvenn

I am just trying to argue that Babel should let people use it, the way they want, if they wish to. And by using it, I mean developing a plugin that would match on that operator and do something.

Unfortunately that is much easier said than done. Keep in mind the request here isn't just "add this operator", it's "add this operator and support it from now on", which isn't something we generally do until something is officially stage 0.

Alternatively "support a framework for third-party plugins" sounds awesome, but unless you can tell me a way to do with without severely hindering out ability to maintain Babel as a whole, it won't happen any time soon.

Hi @loganfsmyth, like i said above, i totally agree that the current PR cant be merged and the issue should be closed. However I do believe it highlights one issue with the parser given it cant properly parse |> at the moment and that is something that should be addressed.

Thanks for pointing out that the parser now lives in its own repo @hzoo , I guess it makes things even easier.

@mindeavor would you mind creating a PR on the babylon repo in order to allow it to properly parse both <| and |> ?

i totally agree that the current PR cant be merged

would you mind creating a PR on the babylon

Those are conflicting statements. The parser is a different repo, but the policy is still the same.

I fail to see how it's a conflicting statement ? I am only asking that the parser can properly match on |> with no behaviour whatsoever...

So that the community can be free of creating babel plugins that can use |> as an operator for whatever transformation they want.

I think it would be because

I am only asking that the parser can properly match on |> with no behaviour whatsoever...

Asking that the parser match on it is the same thing as supporting it. It should error because it's not valid javascript or a stage-0 proposal.

Workaround is to use overload currently valid symbols like mentioned or do make a syntax extension yourself by forking babylon atm.

Babel/Babylon has a certain responsibility to limit the scope of what we allow to be parsed. Babel has found itself as part of the standards process and used by tens of thousands of developers. If we add lots of different grammars that are unstandardized we can quickly find ourselves in a bad place where we have to make breaking changes to Babel in order to keep up with diverging standards.

This may seem hypocritical because we support for JSX and Flow. However, both of those are so mainstream that the TC39 would already have to consult the creators and consider them as part of the standards process if they were to ever try to standardize them. Luckily the people who created JSX and Flow are on TC39.

I understand that people want to use Babel for experimentation. It's how Babel was born to begin with. However, you're encouraged to fork Babel and/or Babylon and experiment on your own. We can't burden the community with every grammar idea that people come up with.

Thanks for taking the time to elaborate and clarify on where Babel stands @thejameskyle.

It's a little bit sad to hear because making it easy for people to prototype and share potential future javascript syntax improvements seemed like part of the core goals of Babel initially and it has been lost along the way.

The sharing part is the missing piece right now and it would be great if Babel would at the very least, make it easy to plug a custom parser / a fork of babylon.

Keep in mind that we're generally willing to accept someone once it is officially stage 0. There aren't a lot of requirements for that, https://tc39.github.io/process-document/, but it does mean that there there needs to be some kind of indication that it would be considered as possible for the language. The syntax doesn't need to be perfect, but if it can't get to stage 0, there is little chance of it making it into the language, and if that's the case, adding it to Babylon would mean we're essentially maintaining a fork of JS indefinitely.

People can absolutely use Babel as a testbed for new features so that people making proposals can validate their ideas, and that's exactly what this PR is, which is awesome. At the moment though, we're not aiming to be a perfectly pluggable system for entirely arbitrary syntax. Maybe one day, but we've got enough bugs with the system as it is, trying to maintain a syntax plugin system on top of that would likely to too much for us at this point.

@tlvenn with #3561 you can pass a different parser/generator

@loganfsmyth Ya issue is as someone pointed out on twitter recently if you're on tc39, almost any idea you have can be stage0. not on tc39, huge uphill just to get to stage0. Even being "proposed" is a big step, since u have to get a champion. most ideas struggle there. huge member advantage.

@hzoo Thanks for the PR link, exactly what I was looking for !