Skip to content
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

Don't default parser to babylon #4426

Closed
wants to merge 5 commits into from

Conversation

suchipi
Copy link
Member

@suchipi suchipi commented May 5, 2018

Fixes #2884

I couldn't figure out where to put the warning message; the inferParser logic is buried in normalizeOptions, but the logger is in the context at the util-level. Could I get some help on that part?

Also, another consideration for the warning message is that it should be slightly different when they are using stdin (should probably mention using --stdin-filepath, etc).

@suchipi suchipi added type:infra Issues about CI, publishing to npm, or similar area:cli Issues with Prettier's Command Line Interface status:wip Pull requests that are a work in progress and should not be merged labels May 5, 2018
["--parser", "babylon", "--debug-print-doc"],
{ input: "0" }
).test({
stdout: '["0", ";", hardline, breakParent]',
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure why this changed, but the new output looks better than the old output, to me

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think maybe this printed content was being formatted with the babylon parser before (it was interpreting it as an ExpressionStatement > ArrayExpression and adding a semicolon)

@@ -30,7 +36,9 @@ test("doesn't insert second placeholder for nonexistent TypeAnnotation", () => {
foo('bar', cb => {
console.log('stuff')
})`;
expect(prettier.formatWithCursor(code, { cursorOffset: 24 })).toEqual({
expect(
prettier.formatWithCursor(code, { parser: "babylon", cursorOffset: 24 })
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's worth noting that you now must specify a parser when using the API, or your code will be passed through as-is. This might be counter-intuitive, and is a bit more of a breaking change than the CLI fix. We might want to default to babylon, but only when using the API directly.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can go back to #2884 and ask/ping if anyone's using the API without both filepath and parser and relying on the babylon fallback

locStart() {
return 0;
},
locEnd(node) {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had to add locStart and locEnd to get the cursor-related tests passing; are these required on all parsers now? If so, we should update the documentation.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is documented: https://prettier.io/docs/en/plugins.html#parsers

I don't know if it was intentional. Since we need those for comments and other stuff, we just assume they are always present and call them. I guess we could do a check if they're present and disable those functionalities if they're not, but I don't know if it's worth the trouble.

Copy link
Member

@kachkaev kachkaev May 5, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@duailibe it might. In https://github.com/gicentre/prettier-plugin-elm that I maintain locStart and locEnd make over 50% of code, but I have no idea what they are doing and how 😅 I just copied them from the python plugin and could not delete without breaking things.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

locStart and locEnd are supposed to take in a node and return the index in the source code where said node starts or ends, respectively.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand what they're for, I just didn't think they were required.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at the docs again now, I totally misread them, my bad

"1;
"
`;
exports[`write cursorOffset to stderr with --cursor-offset <int> (stdout) 1`] = `" 1"`;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure why these changed... @ikatyang could you spot-check?

Copy link
Member

@ikatyang ikatyang May 6, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like the correct change:

  • with babylon:

    before (offset=2)

     1|
    

    after (offset=1)

    1|;
    
  • with raw:

    before (offset=2)

     1|
    

    after (offset=2)

     1|
    

@duailibe
Copy link
Member

duailibe commented May 5, 2018

I'll see if I can figure out why the outputs changed later. In the meantime, can you add a test for formatWithCursor and when using the range feature (when using the raw parser)?

@@ -85,8 +85,9 @@ const options = {
since: "0.0.10",
category: CATEGORY_GLOBAL,
type: "choice",
default: "babylon",
description: "Which parser to use.",
default: "raw",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

default: [
{ since: "1.8.2", value: true },
{ since: "1.9.0", value: "preserve" }
],

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will do

@ikatyang
Copy link
Member

ikatyang commented May 6, 2018

I couldn't figure out where to put the warning message; the inferParser logic is buried in normalizeOptions, but the logger is in the context at the util-level. Could I get some help on that part?

I guess we can add a new field message or something to parser's choiceInfo and then show the warning in normalizeOptions based on that field:

parser: {
  choices: [
    { value: "raw", message: "blahblahblah" }
  ]
}

@lydell
Copy link
Member

lydell commented May 6, 2018

In #2884 (comment) I was more thinking about prettier foo.unknown not doing anything except printing a warning message. I had not a “raw” parser in mind. Do we need it?

@suchipi
Copy link
Member Author

suchipi commented May 6, 2018

@lydell We don't need it, it was just the way I found to implement it.

@suchipi
Copy link
Member Author

suchipi commented May 6, 2018

@ikatyang one problem with showing the warning in normalizeOptions is that we call it more than once during normal use, so the warning would get printed multiple times. I looked into implementing a hash map of files that we've already warned about but it felt really messy.

@suchipi suchipi added this to the 1.13 milestone May 9, 2018
@suchipi
Copy link
Member Author

suchipi commented May 15, 2018

If someone has some time to figure out the logging part of this, I would greatly appreciate it. Otherwise, it'll get done when it gets done; still planning on it being in 1.13 though unless something comes up

@suchipi
Copy link
Member Author

suchipi commented May 23, 2018

Closing; superceded by #4528

@suchipi suchipi closed this May 23, 2018
@lock lock bot added the locked-due-to-inactivity Please open a new issue and fill out the template instead of commenting. label Aug 21, 2018
@lock lock bot locked as resolved and limited conversation to collaborators Aug 21, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area:cli Issues with Prettier's Command Line Interface locked-due-to-inactivity Please open a new issue and fill out the template instead of commenting. status:wip Pull requests that are a work in progress and should not be merged type:infra Issues about CI, publishing to npm, or similar
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants