<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>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?</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Rob</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Michael Krotscheck <<a href="mailto:krotscheck@gmail.com">krotscheck@gmail.com</a>><br>
<span style="font-weight:bold">Reply-To: </span>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Date: </span>Tuesday, 16 June 2015 00:36<br>
<span style="font-weight:bold">To: </span>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Subject: </span>[openstack-dev] [javascript] [horizon] [merlin] [refstack] Javascript Linting<br>
</div>
<div><br>
</div>
<div>
<div>
<div dir="ltr">I'm restarting this thread with a different subject line to get a broader audience. Here's the original thread:
<div><a href="http://lists.openstack.org/pipermail/openstack-dev/2015-June/066040.html">http://lists.openstack.org/pipermail/openstack-dev/2015-June/066040.html</a><br>
</div>
<div><br>
</div>
<div>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:</div>
<div>
<ul>
<li>Horizon currently uses JSCS.</li><li>Refstack uses Eslint.</li><li>Merlin doesn't use anything.</li><li>StoryBoard (deprecated) uses eslint.</li><li>Nobody agrees on rules.</li></ul>
</div>
<div><b>JSCS</b><br>
</div>
<div>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.</div>
<div><br>
</div>
<div><b>JSHint</b></div>
<div>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.</div>
<div><br>
</div>
<div><b>ESLint</b></div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Michael</div>
</div>
</div>
</div>
</span>
</body>
</html>