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

Prettier 1.0

jlongster.com

Post reply on HN
Print view View original

71–78 of 78 posts

Re: Prettier 1.0

#71

Post by paulddraper »

llimllib wrote: post #63
vmasto wrote: post #14

I recall the React team were discussing at what part of the build step they should include Prettier. I believe there was an idea of adding it as a pre-commit hook, a second one as a manual step and another one as a post-commit amend. Have we reached a consensus on that? Not up to date what they went with, what seems to be the best way to do this?

I run it at pre-commit and in CI before approving a PR. Basically my thought is to trust my team to do it whatever way they want to, in the editor, manually, or as a commit hook; and then verify it on the backend before committing.

This is exactly right. First project I saw using this approach a couple years ago was Play Framework + scalariform.

Re: Prettier 1.0

#72

Post by gknoy »

jaredklewis wrote: post #68
mrkgnao wrote: post #48

Earlier quoted context omitted.

While I understand the reasons for this (especially with the culture, for lack of a better word, around Go), I feel like this is a step backward in general. The "standard" Haskell formatter, hindent, did something similar. I found the maintainer's behavior admirable -- the style that was agreed on was very different from his own, but it was what he saw after analyzing publicly available code -- but what's the problem…

What's the advantage of project specific, custom formats?

It allows everyone in your company's dev organization share a common `standard` of JS style, which you have agreed on, even if it differs slightly in the way it bikesheds things like single-vs-double quotes or the presence of semicolons. (I mention `standard` because we use it as the basis for our linting rules, and would LOVE to use prettier to reformat our code.)

Re: Prettier 1.0

#73

Post by dilap »

mrkgnao wrote: post #48
bradfitz wrote: post #45

Earlier quoted context omitted.

We had configurability in early versions of gofmt but realized it was a mistake and kinda missed the whole point of having a code formatter, so we removed them.

While I understand the reasons for this (especially with the culture, for lack of a better word, around Go), I feel like this is a step backward in general. The "standard" Haskell formatter, hindent, did something similar. I found the maintainer's behavior admirable -- the style that was agreed on was very different from his own, but it was what he saw after analyzing publicly available code -- but what's the problem…

it's something that doesn't matter that you don't ever have to worry about again. it's a huge win.

Re: Prettier 1.0

#74

Post by jacobr »

What's the best way to add this to an existing project?

Going through all code at once would destroy all relevant vcs history and git blame. Maybe before each substantial edit on a file first run it through prettier and then make your real changes in a separate commit?

Re: Prettier 1.0

#75

Post by antirez »

jlongster wrote: post #56
antirez wrote: post #38

I'll never understand code formatters. For me the idea of my code passing through a formatter, is like if accidentally I lost part of it: there is a lot of care in the way you write your code, even in the part that the compiler does not care about: spaces. Spaces are the rhythm of the code... not sure why one would write code without rhythm and later add a synthetic one.

You might be surprised at the quality of the output (obviously I'm biased). We've tried to choose what most people consider to be the best way to style code, and many times prettier ends up formatting complex code better than I would have manually. Also, the biggest benefit that a lot of people don't realize is it allows you to quickly restructure your code easily: http://jlongster.com/s/refactor.gif I understand if…

Hello! Don't get me wrong, I'm not saying that code formatters are not useful, they are massively useful in order to turn badly formatted code into more readable code, and also when there is to integrate some code from a code base to another and needs to be re-formatted and so forth. What I find odd is that there are people using it as a "to go" solution for code indentation. The fact btw that it keeps the original blank lines is a great feature that saves a lot of semantics. Thanks for your comment!

Re: Prettier 1.0

#76

Post by josephfrazier »

jacobr wrote: post #74

What's the best way to add this to an existing project? Going through all code at once would destroy all relevant vcs history and git blame. Maybe before each substantial edit on a file first run it through prettier and then make your real changes in a separate commit?

You can have git diff/blame/etc ignore stylistic changes by configuring prettier as a textconv [1]. I'm building a `git diff` wrapper that does this for you [2].

[1]: https://git.wiki.kernel.org/index.php/Textconv

[2]: https://github.com/josephfrazier/prettier-diff

Re: Prettier 1.0

#77

Post by vmasto »

danabramov wrote: post #69
vmasto wrote: post #14

I recall the React team were discussing at what part of the build step they should include Prettier. I believe there was an idea of adding it as a pre-commit hook, a second one as a manual step and another one as a post-commit amend. Have we reached a consensus on that? Not up to date what they went with, what seems to be the best way to do this?

We currently do the same thing Jest does: no hooks, but we offer it as `npm run prettier`, and we also run the comparison on CI (so if the prettier output is different, the PR fails). This means the code is always checked in formatted, but people need to remember to run `npm run prettier` or CI will fail.

Interesting, thanks Dan.

Re: Prettier 1.0

#78

Post by WhitneyLand »

rattray wrote: post #19
WhitneyLand wrote: post #15

Earlier quoted context omitted.

Can it handle escaped json string constants? For example this: http://whitneyland.com/2017/04/first-in-the-world-to-display...

You can try prettier online at https://prettier.github.io/prettier/ Not sure exactly what you mean, but here's an example with JSON: https://prettier.github.io/prettier/#%7B%22content%22%3A%22x... Prettier doesn't support JSON files per se (and doesn't currently plan to [0]), so you need to provide a leading `x = {...` or similar to ensure the { is parsed as an object instead of a block. [0] https://github.com/pretti…

Looks like it has no understanding of json at all.

If you have a constant like this, except really long and ugly, there's quite a bit that can be done to make the code more readable.

Maybe I'll add an issue and see if anyone else cares about it.

var simpleJson = '{ "DevelopersNeedUXToo": [ { "Color": "Red", "Name": "Lee" } ] }'

Post reply on HN