<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>* We should be able to write custom "linter" rules
looking for common issues with Mozilla code (e.g. usage of
nsIFile over OS.File)<br>
</div>
</div>
</div>
</div>
</blockquote></span>
Right. So as Boris said, most of this just needs parsing and "glue"
to process the AST and hook up to our custom processing
scripts/specifications (for refactors/reformatting/linting).<br>
<br>
Do you have evidence that a significant number of the above problems
have ready-made "glue" that will work with ES6 once we get rid of
the SM-specific stuff? Because we already have a working parser and
AST generator - Reflect.parse. Its output format, last I checked, is
largely compatible with the existing toolset. The main problem was
ES6 stuff like "let", "const", "yield", generators, for...of, and
destructuring expressions. Ditching SM-specific things wouldn't
bridge that gap. Maybe I've been looking at the wrong tools, though?<br></div></blockquote><div><br></div><div>Have a look at ESlint <<a href="http://eslint.org/docs/about/" target="_blank">http://eslint.org/docs/about/</a>>. It's moving very fast to support ES6 stuff on an opt-in basis; <<a href="http://eslint.org/docs/configuring/" target="_blank">http://eslint.org/docs/configuring/</a>> has details. It already has a very large chunk of the es6 features we use; see <<a href="http://eslint.org/docs/configuring/" target="_blank">http://eslint.org/docs/configuring/</a>>. It's also designed to be pluggable so that we can add rules to match our own prevailing style usages.</div><div><br></div><div>Dan</div></div></div></div>