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

Formatting: if condition line comments #64

Open
helixbass opened this issue Mar 24, 2019 · 1 comment
Open

Formatting: if condition line comments #64

helixbass opened this issue Mar 24, 2019 · 1 comment

Comments

@helixbass
Copy link
Owner

There's some instability around trailing if condition comments. Eg this:

if token.comments # `comments` is always an array.
  d

formats like

if token.comments
  # `comments` is always an array.
  d

while if it has an initial indent:

  if token.comments # `comments` is always an array.
    d

it formats like

if (
  token.comments # `comments` is always an array.
)
  d

Probably should always try and print inline (like the first example source) when it fits? Moving into the body (like the first example formatted) seems wrong

@helixbass
Copy link
Owner Author

helixbass commented Apr 26, 2019

So the discrepancy between the two versions was due to a location data bug in the Coffeescript dependency (updated)

Now (on iss64-if-condition-comment) both format like the second example (where the condition breaks)

(but this also messed with the formatting of tests/comments/if.coffee, see branch diff - needs to get sorted out)

In order to get it to print inline, we'd need to somehow override the fact that Prettier's printTrailingComment() includes a breakParent

Slightly similar to what I ran into in #122, it seems like currently it's sort of all-or-nothing with using Prettier's comment-printing. prettier/prettier#5087 seems to be aimed at changing that

But in the meantime maybe I should look more closely at what those other plugins are doing as workarounds - sounds like they're copy-pasting some of the individual Prettier functions but segregating them eg to their own module

Also, my understanding is that in order to avoid Prettier's own comment-printing kicking in, you have to use willPrintOwnComments(), but would be nice to see if that's the pattern other plugins are using

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant