Implement f# pipeline in parser

[mAAdhaTTah]

Q	A
Fixed Issues?	#6889
Patch: Bug Fix?	No
Major: Breaking Change?	No
Minor: New Feature?	Yes
Tests Added + Pass?	Yes
Documentation PR Link	TODO
Any Dependency Changes?	No
License	MIT

This is still very much "Work-in-Progress", but since I mostly don't know what I'm doing, I wanted to get this up early so I can get some feedback on alternate approaches, suggestions on the AST, etc. The two main things left are:

• await parsing
• arrow body parsing

cc @js-choi @littledan

[babel-bot]

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

[mAAdhaTTah]

Just pushed solo await parsing in the pipeline, courtesy of @thiagoarrais. Want to confirm the tests pass, but will also be pushing some tests so Thiago & I can collaborate on them.

[mAAdhaTTah]

Actually may have gotten parenless arrow functions parsing. cc @littledan & @nicolo-ribaudo Definitely interested in suggested tests to add here / what cases I haven't covered.

[mAAdhaTTah]

Note that this AST is a modified implementation of what I inquired about here. The idea is to treat the PipelineHead & PipelineBody differently in regards to how they interact with arrow bodies. The operator will will terminate an arrow body when it's within a PipelineBody but not within a PipelineHead, allowing us to write:

x => x |> y => y + 1 |> z => z * 2

which parses as (fully paren'd):

x => (x |> (y => y + 1) |> (z => z * 2))

I don't know yet if the fact that it's feasible in babel means it's feasible from a spec perspective. Will need those with more expertise to weigh in.

Also note that accepting F# w/ parenless arrows may conflict with the movements toward making Smart Pipelines a superset of F# Pipelines.

[nicolo-ribaudo]

Question: why do we need the PipelineHead and PipelineBody nodes?

Can't a |> b just be BinaryOperator(op: |>, left: Identifier, right: Identifier)? They can be parsed differently even if the nodes aren't present in the AST.

[mAAdhaTTah]

Question: why do we need the PipelineHead and PipelineBody nodes?

My understanding of the spec was we needed the different nodes to provide different precedence values related to the arrow function, depending on whether it's in the Head or Body. But this is not my strong suit, so I would need someone else to weigh in here.

[nicolo-ribaudo]

I think that we should remove those nodes if (and only if) it is possible to understand if a node is the equivalent of a PipelineHead only by checking it's parent: this is how we disambiguate those cases in babel or babel/generator.

To my understanding, if t.isBinaryExpression(node, { operator: "|>" }) && !t.isBinaryExpression(node.left, { operator: "|>" }), then node.left is a pipeline head. Is it correct?

[mAAdhaTTah]

@nicolo-ribaudo Yeah, that's correct. I can remove those nodes, but we do want to keep babel's produced AST in line with the spec, correct? If so, and we decide the spec requires them, would changing the AST be a breaking change? I'm not entirely clear on the spec needs here, and my understanding is Babel's AST should match the spec's AST, so I want to make sure we keep them in alignment before we remove anything. That said, I could easily be wrong about the spec's needs here, so I want to keep an eye on potential paths forward as we settle on the F# parenless AST.

[mAAdhaTTah]

It occurred to me this might be fixed in master. Merged that up.

Dismissing approval because the test I commented asking to add a comment in the code was actually wrong

[buildsize]

File name	Previous Size	New Size	Change
babel-preset-env.js	2.27 MB	2.05 MB	-232.03 KB (10%)
babel-preset-env.min.js	1.3 MB	1.1 MB	-211.58 KB (16%)
babel.js	2.8 MB	2.78 MB	-27.89 KB (1%)
babel.min.js	1.56 MB	1.55 MB	-13.02 KB (1%)

[mAAdhaTTah]

@nicolo-ribaudo Addressed your comments / questions. I think we still need PipelineBody, but can update that if you think we don't.

[nicolo-ribaudo]

#9450 (comment)

I think so. The Smart proposal has a PipelineBody node as well.

Actually it looks like it's defined in types.js but it is never created in the parser. The Smart proposals has nodes like PipelineBareFunction, but it's there because it's different from a simple identifier/member expression.

Also, in the Smart proposal makes sense to have different nodes since, for example, a PipelineBareFunction and a PipelineTopicExpression have different meanings, while in the F# proposal it would always only be PipelineBody

[mAAdhaTTah]

Removed the PipelineBody node from the AST.

[hzoo]

Nice work!

Was wondering (not specific to this PR) about how we would go about removing the different options in the future (once a proposal moves forward). I guess with the new state it doesn't seem that bad to remove (wish it was easier but unlikely that is possible to do easily). But would love to write more docs on the overall process we are going to take moving forward regarding multiple proposals and also the lifecycle of this process (implementation, deprecation, removal, acceptance, etc)