<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Jun 8, 2015 at 1:59 AM Matthias Runge <<a href="mailto:mrunge@redhat.com">mrunge@redhat.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
jshint: still non-free license [1]<br></blockquote><div><br></div><div>Yep! Ergo, we can't really use it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">eslint seems to require to sign a CLA, if we come across an issue and<br>
were going to fix that.<br></blockquote><div><br></div><div>So does the python foundation, I'm not really worried about it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">jscs seems to be the utility, cool kids are using. As expected, it<br>
requires node. It has seen 3 releases within 3 months, or 5 in 4 months.<br></blockquote><div><br></div><div>Google trends disagrees with this assertion:</div><div><a href="https://www.google.com/trends/explore#q=eslint%2C%20jscs%2C%20jshint%2C%20jslint&cmpt=q&tz=">https://www.google.com/trends/explore#q=eslint%2C%20jscs%2C%20jshint%2C%20jslint&cmpt=q&tz=</a><br></div><div><br></div><div>Also, as a random aside, I have read things On The Internet (tm) that say that eslint is better about doing PMD things like scope variable overrides and unused parameters. Not having used JSCS, I can't really comment.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My question here would be: how are we going to handle changes here over a release (and how to keep this running on the gate for released<br>
versions)?<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"></a><br>
</blockquote><div><br></div><div>The required version of eslint is actually defined per project, in package.json. As long as the project does NOT use fuzzy version matching (~1.x.x), the build should remain reliable.</div><div><br></div><div>Furthermore, all 'lint' builds are abstracted behind the `npm run lint` command, and is definable by project, so specific changes to the linting configuration are committed to the codebase. Here's an example:</div><div><a href="https://review.openstack.org/#/c/185711/5/refstack-ui/package.json">https://review.openstack.org/#/c/185711/5/refstack-ui/package.json</a><br></div><div><br></div><div>Michael</div></div></div>