add prettier for better format

[zh99998]

Bug Report or Feature Request (mark with an x)

- [ ] bug report -> please search issues before submitting
- [x] feature request

currently tslint and .editorconfig can do some code style normalize but they do too less

using prettier could normalize more code style, less difference, it's much useful in some team allow different IDE.

[filipesilva]

We had a code formatter some time ago (clang) but removed it. I agree having a common formatter helps but it's very dependent on the team.

[zh99998]

recommend a code style as default, but also allow some customize, will be good.

just like tslint, angular-cli use ... for example no-inferrable-types by default.
It will suit most teams, but still configurable when need.

prettier could be same. It allow custom line width, indent, semicolons, quotes, tailing commas, and more. angular-cli can recommend a config, and leave it configurable for people in need.

currently, even official angular modules using different code style, for example in Angular Material2 document, there is no space in import brackets
https://github.com/angular/material2/blob/master/src/material-examples/autocomplete-filter/autocomplete-filter-example.ts#L1

import {Component} from '@angular/core';

but in angular-cli generated file, there is.

angular-cli/tests/e2e/assets/1.0.0-proj/src/app/app.component.ts

Line 1 in d21caad

import { Component } from '@angular/core';

I think this is not good.
add a formatter can avoid most code style problem in practice, it's useful than dependent on the team, further more, team can config it.

[priley86]

@filipesilva @hansl a big +1 for prettier here. It's changed my workflow for the better and I recently found it fixes over 40% of Standard JS Lint rules automagically.
https://gist.github.com/priley86/78093a1f37b39242096c13ddfbe3f701

Is this something you'd be interested in accepting a PR for? Happy to take a stab at this. Would try to ensure tslint integration and follow up on any upstream Prettier issues needed to resolve the integration. I like other formatters like tsfmt, but Prettier is much more powerful and runs on every save (if you let it). This has drastically cut down on dev time, minor es6 bugs, and format reviews...

[aaronfrost]

I would love to be asked when I run ng new blah if I want to add prettier to the project. That would make it so that people who want it can have it... and those who don't... don't.

Prettier makes these never-ending tslint errors go away.

[SanderElias]

I'm with @aaronfrost here. I would love to have prettier added to the CLI. I would even go a step further and don't ask, but install by default, with the possibility to opt-out using a switch.

[rtm]

I'm seriously puzzled why something like this needs to be part of angular-cli. If you want it, then install it.

[aaronfrost]

You could say that about every single piece of functionality in the cli.

[rtm]

@aaronfrost Well, help me out with some specific ideas of the advantages of integrating with angular-cli.

When I read things like "integrate it by default, then offer an option to turn it off", I shudder. I also wonder about what happens when someone stops maintaining prettier, for example. If there is a generic notion of "prettifier" that could usefully be part of angular-cli (maybe there is--personally, I'd prefer my framework not muck with my code to that degre), then shouldn't angular-cli instead provide a generic interface for prettifiers, instead of bundling/hard-wiring a particular one?

[bkinsey808]

I just want to add that a number of formatting specific tslint rules are made unnecessary (and should be removed) if prettier is used. So it would be great to get a prettier compatible tslint config out of the box with the cli either by default or with an option.

[aaronfrost]

@rtm you say that having it on by default makes you shudder. Let me confirm that I felt the same way about TypeScript, about Prettier, about the Angular CLI itself, Observables. I didn't like that I was forced to use them. But I always try it and like it. This is especially true with TypeScript and Prettier.

I realize that I am likely alone in my opinion that ESLint is a pile. I don't need the build to fail because there is a string using single quotes instead of double quotes. Further, getting an entire organization to agree on what should fail the build and what shouldn't is statistically improbable. I don't like ESLint, but I do recognize the need to have uniform code bases.

Prettier is like the middle ground. You get good formatting, and you don't get failed builds. It's pretty fantastic. I won't ever do a project without it. So, with that explanation, I would caution people to be more open to Prettier. If the Angular CLI had it on by default... new Angular projects would be so much easier to work on in teams. We'd get a lot less red squigglies (and I know I'm not the only person who thinks that the default settings in the Angular CLI are too strict). You can't write a line of code without getting red squigglies. Things like prettier are great, because, when you make a change, and get a red squiggle, you just hit Cmd+S to save, and then the reformat happens, and all is well again. No more problem. It's pretty fantastic.

[studds]

@bkinsey808 you can use https://www.npmjs.com/package/tslint-config-prettier to automatically disable the tslint rules that prettier would conflict with.