<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 26/11/2015 11:48, Gijs Kruitbosch wrote:<br>
<blockquote cite="mid:5656F19E.1000207@gmail.com" type="cite">What
is the quickest way we can make this bar higher today? I know
devtools and loop already have some eslint support, but it seems
that ./mach eslint can't deal with preprocessed files or with
|const| . That won't work for the vast majority of our files. How
hard is it to fix that and start using this more systematically?
Patrick/Nick/Dan, can you clarify?
<br>
</blockquote>
I suspect that preprocessing would require some sort of plugin, I
suspect writing one could be hard due to knowing whether or not to
follow certain options. However, I'd also suggest we should speed up
the effort to remove preprocessor flags from js code (<a
href="https://bugzilla.mozilla.org/show_bug.cgi?id=1150859">bug
1150859</a>).<br>
<blockquote cite="mid:5656F19E.1000207@gmail.com" type="cite">
It doesn't seem like the non-existing variables thing as-is is
caught by ./mach eslint today - not even for cases where there is
an argument that is within a short Levenshtein distance of an
identifier used in the function. Does ESLint support some way of
indicating available globals and enforcing code doesn't depend on
globals that aren't available? (I know that some of the JS
minification tools support things like this, so I'm a little
surprised not to see it mentioned for ESLint...)<br>
</blockquote>
There's no real "global" configuration for eslint today. So it will
only catch a couple of very basic things unless you add to the
configuration. You'd either need to turn on the <a
href="http://eslint.org/docs/rules/">"recommended"</a> set, or the
rule itself: <a class="moz-txt-link-freetext" href="http://eslint.org/docs/rules/no-unused-vars">http://eslint.org/docs/rules/no-unused-vars</a><br>
<br>
For the globals, these can be specified in either the .eslintrc
file, or there are <a
href="http://mxr.mozilla.org/mozilla-central/source/testing/eslint-plugin-mozilla/">plugins</a>
that the devtools team have written to deal with our XPCOM imports
and other things.<br>
<blockquote cite="mid:5656F19E.1000207@gmail.com" type="cite">One
thing that might be possible short term is to set up an
infrastructure job that runs eslint on all the "shipped" JS source
files (probably not as part of mochitest because I expect it'll be
too slow). That avoids the preprocessing issue, but we'll still
need it to deal with the "we use ES6" thing...
<br>
</blockquote>
eslint can already <a
href="http://eslint.org/docs/user-guide/configuring#specifying-language-options">cope
with a lot of es6</a>. There are some constructs that we use that
are Mozilla specific, or there may be some things that are so new
they don't work in eslint yet. We can either not use them, or write
plugins, or get eslint extended.<br>
<br>
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), but turn on a couple of rules for an area. Then, once
the infra is in place, we can add more as we go.<br>
<br>
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".<br>
<br>
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.<br>
<br>
The biggest win I find, is the editor integration. I know it can be
integrated into Atom and Sublime (probably more) to give almost
real-time updates, this means I'm fixing typos and issues before I
even save/run the code saving lots of time.<br>
<br>
Mark<br>
</body>
</html>