Pipeline operator support

[hezyin]

I realize that pipeline operator is still experimental at this stage and understand if we don't plan to support it in the short term. But if I'd like to parse code that uses |> without error, is there an easy way to modify the source to do it? Thanks in advance!

[issue-label-bot[bot]]

Issue-Label Bot is automatically applying the label feature_request to this issue, with a confidence of 0.69. Please mark this comment with :thumbsup: or :thumbsdown: to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

[mjambon]

As of April 2022, the proposal for the pipeline operator |> is now in stage 2 (Draft) toward adoption by ecmascript: https://tc39.es/proposal-pipeline-operator/ This corresponds to the so-called "Hack-style pipeline operator" which is one of the 4 syntaxes/semantics supported by Babel but is now the default and only recommended variant (https://babeljs.io/docs/en/babel-plugin-proposal-pipeline-operator).

The only uncertainty is about the % placeholder, which the ecmascript draft says might change. I think we should implement the current proposal anyway in tree-sitter-javascript and change it later if needed by the definitive standard. Please give me a :+1: or :-1:. If people think we should wait, we would add it only as an extension of tree-sitter-javascript/typescript in semgrep.

[maxbrunsfeld]

In my opinion, we should wait until proposals are finished before adding them here, unless there's significant evidence that they're very widely used.

There's a lot of syntax changes in stage 2 that seem pretty likely to change before they ever gain widespread adoption: tuples, module blocks, records, and throw expressions. How do you think pipeline expressions compare to all of these other things?

To be fair, we already did add decorators, even though they're only at stage 3. So I'm not exactly sure what our policy should be. @mjambon What policy do you think makes the most practical sense, as a general approach?

[aryx]

Our general approach I think has been how many complaints we get about a parsing error :) especially whether those complaints come from paying customers.

[mjambon]

@maxbrunsfeld sorry for the late reply.

Here's what @nmote said in a private conversation:

TC39 moves slowly. when I was on Flow we usually considered proposals for support when they reached Stage 2, unless there was still a lot of remaining controversy around the change. we were never burned by adopting these things early, and our users appreciated it.

So I think it boils down to how confident we are that the proposal is going to stick. A threshold of 80%+ confidence seems about right, meaning we'll have to change our implementation later in 1 case out of 5.

Changing syntax later is not really a problem for Semgrep. Would it be a problem for other users of tree-sitter?

[maxbrunsfeld]

That makes sense. I want this parser to be useful to people, and if Semgrep is getting complaints from customers who are using the pipeline operator in their codebases, then that's a good signal that many people are using this feature. Let's add it! Thanks for calling out this issue @mjambon.

[yruss972]

Any update on this?