Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Prettier JavaScript Formatter

jlongster.com

Post reply on HN
Print view View original

41–50 of 159 posts

Re: A Prettier JavaScript Formatter

#41

Post by runarberg »

wnevets wrote: post #20

am I the only one who dislikes spaces after braces? i.e foo({ num: 3 },

I used to like the style of space padded block statements but not object literals:

    foo(function() { return {num: 3}; });
I used that a lot when writing code that used D3. But since arrow functions, I hardly ever use a single line block statements, so this style is obsolete.

Re: A Prettier JavaScript Formatter

#42

Post by imh »

tomp wrote: post #14

Nice attempt, but currently wrong. For example, it pretty-formats this code: function makeComponent() { return /*test*/ { a: 1 }; } into function makeComponent() { return /*test*/ { a: 1 }; } From my own experience writing a formatter, comments are very difficult (if one wants to preserve them). I guess the author should reparse the generated code to ensure the AST hasn't changed.

I don't do much serious JS. What's the problem there?

Re: A Prettier JavaScript Formatter

#43

Post by dustinswan »

imh wrote: post #42
tomp wrote: post #14

Nice attempt, but currently wrong. For example, it pretty-formats this code: function makeComponent() { return /*test*/ { a: 1 }; } into function makeComponent() { return /*test*/ { a: 1 }; } From my own experience writing a formatter, comments are very difficult (if one wants to preserve them). I guess the author should reparse the generated code to ensure the AST hasn't changed.

I don't do much serious JS. What's the problem there?

The first one returns an object, the second one returns undefined

Re: A Prettier JavaScript Formatter

#45

Post by the_duke »

chc wrote: post #33
SomeCallMeTim wrote: post #29

Flow is cool, but TypeScript has way more traction. Would jump on this in an instant if it had TypeScript support and a VS Code plugin.

Typescript is another language. It kind of goes without saying that people using a different language be more likely to use something if it were in the language they use, doesn't it?

Typescript aims to be a superset of ES6+, with all valid Javascript also being valid Typescript (at least syntax wise).

So while it is another language, it is very much related.

Re: A Prettier JavaScript Formatter

#46

Post by gknoy »

jlongster wrote: post #25
wnevets wrote: post #20

am I the only one who dislikes spaces after braces? i.e foo({ num: 3 },

That's actually one of the few config options. Pass `--bracket-spacing=false` to turn off that spacing (or `bracketSpacing: false` in the API)

This tool looks amazing! Would you consider adding a flag for whether to terminate statements with a semicolon, or consider accepting a PR that added such an option? (My team is all-in on `standard`, so I'd love to be able to execute this in a way that would be an easy fixer for our linting rules.)

Re: A Prettier JavaScript Formatter

#47

Post by jlongster »

rhengles wrote: post #28

How does this handle tabs vs spaces? I looked the post, the repo and the issues page and I didn't find anything. I'm specially concerned about not seeing this in the options of the API, since there are strong opinions on both sides.

It always prints spaces and you can configure the number of spaces with `--tab-width`.

For tabs/spaces and semicolons I'm considering if we should support those options. We need to figure out the goal of the project: is it to converge on generally a single format, or is it to provide formatting options for a few large groups of people that have different opinions. There are issues on the project discussing this right now.

Re: A Prettier JavaScript Formatter

#48

Post by jlongster »

gknoy wrote: post #46
jlongster wrote: post #25

Earlier quoted context omitted.

That's actually one of the few config options. Pass `--bracket-spacing=false` to turn off that spacing (or `bracketSpacing: false` in the API)

This tool looks amazing! Would you consider adding a flag for whether to terminate statements with a semicolon, or consider accepting a PR that added such an option? (My team is all-in on `standard`, so I'd love to be able to execute this in a way that would be an easy fixer for our linting rules.)

Check out this issue, we are discussing it: https://github.com/jlongster/prettier/issues/12

Honestly, we may never do it. But we're still figuring out if the ultimate goal is to keep to a single style or not.

Re: A Prettier JavaScript Formatter

#49

Post by tlrobinson »

jlongster wrote: post #18
tomp wrote: post #14

Nice attempt, but currently wrong. For example, it pretty-formats this code: function makeComponent() { return /*test*/ { a: 1 }; } into function makeComponent() { return /*test*/ { a: 1 }; } From my own experience writing a formatter, comments are very difficult (if one wants to preserve them). I guess the author should reparse the generated code to ensure the AST hasn't changed.

We do. The entire Flow test suite passes when pretty-printing and re-parsing and comparing ASTs. There are a very few subtle bugs like the one you mentioned above. As noted in the readme, this is a beta. It's certainly more than an attempt.

Running existing codebases through it and comparing the ASTs is a nice idea. Seems like it should be pretty easy to automated it for the top N (100?) JavaScript projects.

Re: A Prettier JavaScript Formatter

#50

Post by adregan »

Can_Not wrote: post #44

I was hoping to see alignment of = and : when declaring variables and objects.

I'm personally not a fan on alignment because of its impact on the project's commit history and diffs. Not saying it's not nice to look at, I just prefer not changing many unrelated lines because a new variable name is one character longer than the names that surround it.
Post reply on HN