JSCS in Horizon has been extended with the John Papa style guidelines to
enforce consistent angularjs code style*. It's no longer just a findbug
tool. I don't have time to investigate - can ESLint perform the same role
for Horizon?
Current Horizon activity involves a whole lot of bringing code into line
with that style (and other JSCS check fails).
Richard
* https://review.openstack.org/#/c/181311/
On Tue, 16 Jun 2015 at 09:40 Michael Krotscheck <krotsch...@gmail.com>
wrote:
> 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
>
__________________________________________________________________________
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
