Is this basically clang-format for JS?
Prettier 1.0
61–70 of 78 posts
Re: Prettier 1.0
#62I can't overstate how freeing coding with prettier has been -- often I'd find myself quickly grokking something and once I finally got it to "work," make sure it was all styled properly. Since using prettier, these things are one-and-the-same, which is a tremendous gain.
Something that's kind of tricky for me and my team is that we disagree on things like indentation and spacing in/around brackets and parens. The disagreement isn't just a "I think it should be done this way..." but "I actually understand code better when it's written this way..." If we were to implement prettier, and chose to use 2-space indents, for a simple example, how would a 4-space developer fare when they pull…
Like rattray mentioned, this is something that I think would be totally doable in Prettier (whether or not it would be wise is a separate issue).
I sort of deal with something like that even just personally. On my work machine I have nice screen real estate, but when I'm on the go on my 11" air I have prettier set up with a more generous character limit so I can see more on screen. If you combined this set up with something like the pre-commit hooks that OITT have suggested, I could then be looking at my own code slightly differently in two machines but the end result would be the same!
Re: Prettier 1.0
#63I 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.
Re: Prettier 1.0
#64The amazing thing, for me, is: 1. Announced 2 months ago 2. Already adopted by, it seems, every major JS project. ( https://twitter.com/jlongster/status/852532847252566017 ) 3. 7000 stars, 100,000 npm downloads/mo Now some people will say it is a better mousetrap, but even now I can't tell you what the difference is between it and all the other linters. I can tell you that, based on the popularity, I would just defau…
Aside from being good software, it was created by a prominent person in the React/JS community and co-developed by a well-known Facebook engineer in the React team. It was lucky to be adopted by large companies quickly, but a) easier to adopt something Facebook approved™ and b) it's painless to adopt since it does everything automatically.
All that, being a great tool, and some Twitter/Medium promotion = success.
Re: Prettier 1.0
#65How does Prettier compare to https://github.com/millermedeiros/esformatter , https://github.com/beautify-web/js-beautify , https://github.com/jedmao/codepainter , https://github.com/rdio/jsfmt , etc.? Personally, I use TSLint with the tslint.autoFixOnSave VSCode setting, and couldn't be happier.
Re: Prettier 1.0
#66I'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.
I think this is because you view yourself as more of a code author, and people excited for this announcement more frequently find themselves in the role of a code reader.
Re: Prettier 1.0
#67Earlier 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…
In the case of Go, it's really advantageous to be able to jump into anyone's project and be able to read it without the additional impedance of adjusting to the new formatting model. I didn't think this would be that significant until I started participating in the Go community. This works together with Go's reduced feature set, so everyone's code ends up looking very similar.
Re: Prettier 1.0
#68Earlier 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…
What's the advantage of project specific, custom formats?
Re: Prettier 1.0
#69I 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.
Re: Prettier 1.0
#70I'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.
There's two reasons, to me, why formatters make a lot of sense. First, working in large teams, not everyone will agree on a formatting convention and it's very difficult for people to internalize the convention and stick to it. This leads to, at best, inconsistencies in the code and, at worst, bike shedding discussions on which conventions to use that distract from shipping actual features. When HBO's Silicon Valley…
I've found this too.
Also: my code formatting has always been a bit unusual, in that I never put spaces in. Compared to what most people do, this is easier to type, because it doesn't require pressing the space bar as much. So code formatters are good for me, because I can keep not pressing space, and now nobody need ever know.
But, guess what: this means code formatters are good for you too. Because now you don't have to press space either.