Open Stack

I’m copying and pasting from the other thread some info below.

I think agreeing on rules is the bigger problem here and I don’t think all
the projects should have to agree on rules. We’ve spent a good portion of
liberty 1 getting the code base cleaned up to meet the already adopted
horizon rules and it is still in progress.

My preference would be to see if we can use eslint to accomplish all of
our currently adopted horizon rules [3][4] AND to also add in the angular
specific plugin [1][2]. But we can’t do this at the expense of the entire
liberty release.

― My previously email below:

We¹ve adopted the John Papa style guide for Angular in horizon [0]. On
cursory inspection ES lint seems to have an angular specific plugin [1]
that could be very useful to us, but we¹d need to evaluate it in depth. It
looks like there was some discussion on the style guide on this not too
long ago [2]. The jscs rules we have [3] are very generic code formatting
type rules that are helpful, but don't really provide any angular specific
help. Here are the jshint rules [4]. It would be quite nice to put all
this goodness across tools into a single tool configuration if possible.

[0] 
http://docs.openstack.org/developer/horizon/contributing.html#john-papa-sty
le-guide
[1] https://www.npmjs.com/package/eslint-plugin-angular
[2] https://github.com/johnpapa/angular-styleguide/issues/194
[3] https://github.com/openstack/horizon/blob/master/.jscsrc
[4] https://github.com/openstack/horizon/blob/master/.jshintrc


From:  "Rob Cresswell   (rcresswe)" <rcresswe at cisco.com>
Reply-To:  OpenStack List <openstack-dev at lists.openstack.org>
Date:  Tuesday, June 16, 2015 at 1:40 AM
To:  OpenStack List <openstack-dev at lists.openstack.org>
Subject:  Re: [openstack-dev] [javascript] [horizon] [merlin] [refstack]
Javascript Linting


So my view here is that I don’t particularly mind which plugin/ set of
plugins Horizon uses, but the biggest deterrent is the workload. We’re
already cleaning everything up quite productively, so I’m reluctant to
swap. That said, the cleanup from JSCS/
 JSHint should be largely relevant to ESLint. Michael, do you have any
ideas on the numbers/ workload behind a possible swap?

With regards to licensing, does this mean we must stop using JSHint, or
that we’re still okay to use it as a dev tool? Seems that if the former is
the case, then the decision is made for us.

Rob



From: Michael Krotscheck <krotscheck at gmail.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Date: Tuesday, 16 June 2015 00:36
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: [openstack-dev] [javascript] [horizon] [merlin] [refstack]
Javascript Linting


I'm restarting this thread with a different subject line to get a broader
audience. Here's the original thread:
http://lists.openstack.org/pipermail/openstack-dev/2015-June/066040.html


The question at hand is "What will be OpenStack's javascript equivalent of
flake8". I'm going to consider the need for common formatting rules to be
self-evident. Here's the lay of the land so far:

* Horizon currently uses JSCS.
* Refstack uses Eslint.
* Merlin doesn't use anything.
* StoryBoard (deprecated) uses eslint.
* Nobody agrees on rules.


JSCS

JSCS Stands for "JavaScript CodeStyle". Its mission is to enforce a style
guide, yet it does not check for potential bugs, variable overrides, etc.
For those tests, the team usually defers to (preferred) JSHint, or ESLint.

JSHint
Ever since JSCS was extracted from JSHint, it has actively removed rules
that enforce code style, and focused on findbug style tests instead.
JSHint still contains the "Do no evil" license, therefore is not an option
for OpenStack, and has been disqualified.

ESLint
ESLint's original mission was to be an OSI compliant replacement for
JSHint, before the JSCS split. It wants to be a one-tool solution.

My personal opinion/recommendation: Based on the above, I recommend we use
ESLint. My reasoning: It's one tool, it's extensible, it does both
codestyle things and bug finding things, and it has a good license. JSHint
is disqualified because of the license.
 JSCS is disqualified because it is too focused, and only partially useful
on its own.

I understand that this will mean some work by the Horizon team to bring
their code in line with a new parser, however I personally consider this
to be a good thing. If the code is good to begin with, it shouldn't be
that difficult.

This thread is not there to argue about which rules to enforce. Right now
I just want to nail down a tool, so that we can (afterwards) have a
discussion about which rules to activate.

Michael