Proposal to replace Clang Format with ESLint and Prettier in phosphor-webui

[Derick]

Thanks for the follow up Ed!

> Prettier:
> I struggle with this one, because as a whole, this project seems to use
> clang-format for most everything else.  In the research I've done, I
> wasn't able to find something that Prettier does significantly better
> than clang-format, with the exception of maybe being more "standard" in
> the javascript realm.  I'd much rather OpenBMC sticks with something
> that's consistent than say every language gets its own formatting library.

I am ok if we don't want to use Prettier for JavaScript, but
clang-format does not
support SCSS and we would like to have consistent formatting in SCSS as well.
We wouldn't expect it to stop the builds, just to ensure code quality. I want
to use the .prettierrc file to keep it consistent for anyone that uses
Prettier and
we can easily ignore .js files in the config. We can also make this a
work in progress
if we don't want to try and resolve all the files up front.

> If ESlint is really something you want to tackle, by all means, but in
> terms of value to the end user, I suspect it's a wash.

I feel the benefit to the user is code quality and to the developer it
is efficiency.
You're correct, the formatting is not something that results in bugs that
require rework. However, clang-format does not surface any potential errors.
It is simply a formatting tool and not one that is widely used in the JavaScript
community (https://www.npmtrends.com/clang-format-vs-eslint-vs-prettier).
ESLint is extremely helpful to people using IDE/Editors like Visual Studio
Code due to it's integration and showing the developer potential problems
in their code as they are writing it. Personally, I have found the
formatting of
ESLint with the Google shared config preferable than clang-format and more
consistent with the formatting most JavaScript projects use.

> If you start with eslint-config-google, the changes are a lot less
> invasive, as we're pretty close to being compliant.

We want to use ESLint based on its ability to catch errors. I did
start with Google's
shared eslint configuration file and it is less invasive. There are
still a few issues to
resolve with that configuration, but if that is the tradeoff for using
ESLint, I'm good with that.

> At one point I had looked at moving forward with Angular 2 and
> typescript, and tried to sketch out the path to get there, but it
> quickly got out of hand.

Agree, that will require effort and time and our team doesn't have the
bandwidth for that.