New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JavaScript: Support Smart and F#-style Pipeline #6319
Conversation
src/language-js/parser-babylon.js
Outdated
[ | ||
"decorators-legacy", | ||
["pipelineOperator", { proposal: "minimal" }] | ||
].concat(extraPlugins) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is bad. I added that as an escape-hatch until I could figure out a decent way to detect which decorator plugin to apply.
This will likely cause a noticeable performance degradation, specially when there's a simple syntax error.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sosukesuzuki Why not always use proposal: 'smart'
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The smart
is compatible with minimal
, but it is coincidental. For example, the same problem will occur again when we try to support fsarp
.
So, I considered generally solution...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as I understand, we'll need to check only smart
and fsharp
then. Why check minimal
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
smart
is not compatible w/ minimal
, so that's not a safe assumption. x |> foo()
is invalid in smart
but valid in minimal
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I see now. That's really unlucky. Hopefully Babel's error recovery might help here.
If it doesn't help, I'm going to make Prettier try using each proposal until the input parses. To avoid overhead, this logic will be used only if the input contains the substring |>
.
In theory we can use babel api to detect plugin, if no plugins found use |
Or we can suppress reparsing attempts if the file doesn't contain the substring |
@thorn0 That would be ideal |
I helped implement the Smart & F# proposals in Babel. Is there anything I can do to help this land? |
@mAAdhaTTah Is there a quick and dirty way (like a regex) to detect which proposal was used in given code without full parsing? |
@thorn0 Not that I can think of. Does prettier read the Babel config? That's probably the most reliable source of which pipeline operator is in use. |
That's the problem, it doesn't read it. And we'd like to avoid that as Prettier's configuration story is already complicated enough. |
468bc38
to
5c58564
Compare
@thorn0 How was this resolved for decorators? Similar approach, or was there something about the various decorator proposals that make this not an issue? |
@mAAdhaTTah The error recovery works really beautifully for decorators. Previously, we had to iterate through different option combinations to find the working one, but now (since v1.19) Prettier even supports different decorator variants within one file. |
@thorn0 Cool alright, if there's anything I can do to adjust the error handling in Babel, let me know, but it might works as-is for this. |
But it doesn't recover from
|
8dd1f7b
to
83157be
Compare
@mAAdhaTTah Could you make those errors recoverable, please? |
@thorn0 I will look into that! |
2b3105e
to
e3269f0
Compare
CI is failing due to memory problem, I may need to increase max-old-space-size or reduce maxWorker of Jest. |
The memory problem happens because |
635b4d4
to
f6aab2c
Compare
cc3762c
to
41ff833
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. Could you add more code to the tests? E.g. from articles like this one.
021097b
to
4193463
Compare
node.body.operator === "|>") | ||
); | ||
} | ||
return false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This leads to a bug:
Prettier pr-6319
Playground link
--parser typescript
Input:
((x) => x) + '';
Output:
(x) => x + "";
} | ||
} | ||
} | ||
return combinations; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's say the input combinations are [["jsx", "typescript"], ["typescript"]]
, in that case the output will be:
[
["jsx", "typescript"],
["typescript"],
["jsx", "typescript", ["pipelineOperator", { proposal: "smart" }]],
...
]
Why do we need the first two elements in this list?
This comment has been minimized.
This comment has been minimized.
Hey folks sorry for a late comment here. Just a question on:
Any reason to link to the fork (67 stars) instead of https://github.com/tc39/proposal-pipeline-operator (4.8K stars)? If no specific reasons, WDYT of changing the link in the 2.1 blog post while it's fresh? |
@kachkaev There are three different pipeline operator proposals: "minimal" (the one you linked to), "f#", and "smart". |
Fix #6162
Support Smart Pipeline and F#-style Pipeline.
More about those proposals ("What's Happening With the Pipeline (
|>
) Proposal?").Smart Pipeline:
F#-style Pipeline:
ref: #7953
docs/
directory)CHANGELOG.unreleased.md
file following the template.