<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 26/11/2015 19:51, Dave Townsend wrote:<br>
<blockquote
cite="mid:CAPMxTNoAtje4wE1TVT4Pi18QFV05bcTFX1NOcJgQ95MY6j8FrQ@mail.gmail.com"
type="cite">
<pre wrap="">Thanks for starting this thread Gijs. As it happens the TAG were
discussing needing to get things like this moving in our meeting
yesterday.
On Thu, Nov 26, 2015 at 5:56 AM, Mark Banner <a class="moz-txt-link-rfc2396E" href="mailto:mbanner@mozilla.com"><mbanner@mozilla.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">From the experience of Hello, I would say the best way to start this would
be to have everything off (which is pretty much the default these days), but31
turn on a couple of rules for an area. Then, once the infra is in place, we
can add more as we go.
</pre>
</blockquote>
<pre wrap="">
How difficult is this to do. Can we get it done next week say and then
maybe spend some time in Orlando tinkering with rules?</pre>
</blockquote>
I did a quick test. Just looking at the browser/ directory, I set up
a minimal .eslintrc in it with just enabling most of the es6 rules.
Here's what I found in the test:<br>
<ul>
<li>316 problems were referenced. Of these, approximately (I'm
counting based on the error messages):</li>
<ul>
<li>64 files failed due to preprocessing requirements, we'd
probably just want to .eslintrcignore these for now.<br>
</li>
<li>A lot (> 120, maybe the majority of the rest), failed due
to yield statements being within functions not designated as
generator functions. That doesn't seem to cause problems, but
it appears to be wrong according to the es6.<br>
</li>
</ul>
</ul>
I also found out:<br>
<ul>
<li>We're going to need to fix our .eslintignore files. Currently
you can only have one .eslintignore at the "root" of the repo.
Loop has one, so if you add one in browser/ then the loop one
gets ignored. That shouldn't be too hard to fix (I think there's
a bug on it somewhere).<br>
</li>
<li>We'll also currently need to ensure we don't disable/enable
extra things for loop currently. The defaults we have are based
on content, and chrome stuff gets enabled as extras per
directory. Again, shouldn't be too hard to fix.</li>
</ul>
<p>From the quick test, I'd say, if one or two people had time to go
through the issues found with the initial test, we could likely
get something close next week. Rules are easy to enable, some
eslint rules can be auto-fixed by eslint. Others you need
manually, but you can enable them one at a time.<br>
</p>
<blockquote
cite="mid:CAPMxTNoAtje4wE1TVT4Pi18QFV05bcTFX1NOcJgQ95MY6j8FrQ@mail.gmail.com"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">For Hello, we turned on a lot of rules very quickly (we had some
contributors step up for good first bugs which helped greatly!), and these
days there are possibly more we'd enable, but we're mainly working along the
lines of, "if I mentioned a nit in a review, is that something eslint could
have caught for us".
At the moment, we have a nag monitor in place, that tells us within a few
hours of landing if something has caused a regression. Getting infra of some
form would good for all of Mozilla.
</pre>
</blockquote>
<pre wrap="">
That's a good start. How difficult is a hg hook that runs lint on
changed and added files? Or something in mozreview?</pre>
</blockquote>
I'd have thought a hook would be reasonable to do. You're basically
running something on the command line. There's also ways to have
eslint run as a service.<br>
<br>
Mark.<br>
</body>
</html>