Using Prettier to format your JavaScript code
wisdomgeek.com
wisdomgeek.com
And contrary to what you might expect, Prettier basically never makes stupid formatting choices. It’s incredibly nuanced.
If this is a new discovery for you, it sounds like you missed out on these things we used to call "IDEs" which were pretty popular more than a decade ago.
I'm just saying that discovering the benefits of automatic code-formatting seems like a very strange thing to do in 2018.
This has been around for a loooong, looong time now.
What on earth would prettier include to make it that much more extensive?
Does VS format on the fly, or only on save ?
The OP didn't even state they're "discovering [it] in 2018", at all. And even if they did, so what? What is the point that you're trying to make -- that you're a better developer because you knew something they didn't?
If that was a common feature in formatting tools more than a decade ago, then I missed it too.
VS Studio and IntelliJ have some language formatting but the difference between them and prettier feels huge.
On the other hand my problem with modern frontend is that fifteen years ago compiling a fairly complicated desktop app and then commiting it to cvs took a couple of seconds (not that the two are related of course). Now webpack cold start is one minute, hot recompilation is between 5sec and 50sec, prepush hook tests a minute or two (and then it is still lightning fast, approx 2k tests in pure jsdom), add prettier, eslint, stylelint, ticket id check to precommit hook and then boom.
We tried to turn stuff off in feature branches, but it seemed to be a bad idea... also note that we're a mixed environment with win, osx, and linux machines and on windows webpack/mocha watchers tend to lock some files randomly, so there is a good chance that someone will choke on a locked file (the ide, git or webpack itself), so I gotta power down the whole thing for branch changes or test watchers.
Also, lint-staged doesn't handle partially staged files properly: https://github.com/okonet/lint-staged/issues/62
Lint-staged can't handle partials, but precise-commits can, though we are using ls for now and will see how much this hurts in terms of partials.
We run `prettier -l` in CI, so it's up to each person to decide how they want to make sure their code is prettier-ed before being pushed.
I'll check out precise-commits, thanks.
Am I alone in being annoyed by this phrase? Most of us here are grown adults, not 14 years old and this isn't high-school anymore.
Sorry if it offended you, meant no harm - maybe little sarcasm about how fast frontend tech moves these days, but that's all.
All these tools just add guarantees to the quality of code in a codebase so that it's easier for a lot of people to work on the same app. Is it slower? Sure. Is it worth it to keep from deploying bugs? Also probably sure.
As a side note, I'd argue that running tests should probably not block you from committing code, but it should keep you from deploying code. I work at a company where our hooks are (usually) pretty fast, but keep you from having to rerun a much larger test suite.
I also love just banging out code without worrying about the formatting then hitting save and having my editor run prettier automatically.
We run it on our entire codebase (https://github.com/metabase/metabase), enforced by CI.
If you decide to migrate an existing codebase to use prettier here are some steps for merging existing branches after you've enabled prettier: https://gist.github.com/tlrobinson/6cad91b1203a7d2c174824a4d...
The only downside to migrating a codebase is it messes with `git blame` etc, but it's not too hard to follow changes back to before you ran prettier.
Here's an example:
const x = !(result instanceof Skip)
? result
: typeof obj === "object"
? traverseObject(Object.keys(obj))
: Array.isArray(obj)
? traverseArray(obj)
: new Skip("Not found.");
const x = items.length
? (() => {
const result = parse(deep(schema, params))
return !(result instanceof Skip) ? result : traverseArray(items.slice(1));
})()
: new Skip("Not found.");
+ Minor edits for clarity
But personally, every identifier being a 'const' instead of a 'let' helps me reason about it much better, especially when the code is purely algorithmic. An alternative might be to use something like Facebook's Reason, where such code can be concise and idiomatic.
function x(result, Skip, obj, traverseObject, treverseArray) {
if(! result instanceof Skip) return result;
if(typeof obj === "object") return traverseObject(Object.keys(obj));
if(Array.isArray(obj)) return traverseArray(obj);
return new Skip("Not found.");
}There is no performance gain, it's not particularly clever. Even if it's formatted better, I doubt this is easier to read than a few if statements for most people.
I bet if Github supports such thing it will become standard
But committing unreadable JSON files to version control rather defeats most of the features of version control.
I've been massively annoyed with the obsession of making the code look exactly the same in every of its parts. Ten years ago, I could tell which of my coworkers wrote a piece of code based on its style only. It was not especially needed, given we had git (and svn before that) to tell who authored a piece of code, but it was pleasant to recognize this or that developer's style. It was not radically different styles, we were still agreeing on tabs vs spaces and how many spaces, it was more subtle. We were authors.
But now that we psychorigidly don't want to see two pieces of individuality in the same codebase, be it as syntax or sometimes even as methods preferences to achieve a task, such tool as prettier or gofmt are incredibly useful. At least, we don't waste time on that.
The only way I can imagine how you never ran into this is that either your team is tiny, or that people don't touch other people's code. Both of which are not an option as you grow.
What I want out of code formatters (for any language, not just JavaScript) is flexible configuration so that I can set up two configurations.
1. A configuration that outputs the style that my employer or the project I'm contributing to has standardized on.
2. A configurations that outputs the style that I prefer.
I picked my styles in the languages I use because they make the code easier to read for me. If the company or project standard style is different I'll be more productive if I can convert my copy to my style while I work on it.
We’ve been using prettier for over a year now at work and it’s been really nice not having to spend much time keeping the code neat. (Works well with typescript and react also)
Wish all languages had this sort of thing. It really has made reviewing and editing code much more pleasant at my company.
```
class Demo extends React.Component<{}, {}> {
someStuff() {
// some code
}; // prettier adds this ; for me, i have to tslint:disable-line every time```
Most new versions of TypeScript expand on their `strict` rules, and just enabling `strict` in your tsconfig, as well as using prettier, is arguably a more robust superset of seatbelts than tslint offered. I deleted tslint from all my TS projects several months ago and don't miss it at all.
Just console.log(JSON.stringify(object)) and paste into your editor. Then just remove the string around it and on save, POOF you have a nicely structured object. Do this with your diff state in another commit and you just diff-ed an insanely large mess of code.
This won't work on online diff tools because the format will be different without prettier.
The one annoying part was the initial roll-out, and a subsequent update, that caused code diffs to be pretty wild. I'd recommend formatting everything at once when you first deploy Prettier. You lose the ability to easily git blame files, but you make everyone's diffs way less horrible.
Oh speaking of, we put prettier in a pre-commit hook, which grabs staged code, prettifies it and re-stages it. Works like a charm. We use https://github.com/okonet/lint-staged to perform this.
P.S. we now have an issue about about integrating Prettier into coala.
Plug: I make StyleCI.
It means that your actual changes will be lost in a big diff of cosmetic changes. I think a better option is to convert the whole codebase in one commit and only after that run it on file save.
ducks
1: http://danmidwood.com/content/2014/11/21/animated-paredit.ht...
It integrates prettier, eslint:fix, and tslint:fix as part of the build process. Uses husky to run as a precommit hook as well.
Life saver when developing.