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 <krotsch...@gmail.com<mailto:krotsch...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, 16 June 2015 00:36
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to