<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 4, 2015 at 8:19 PM, Dave Townsend <span dir="ltr"><<a href="mailto:dtownsend@mozilla.com" target="_blank">dtownsend@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, Dec 4, 2015 at 11:15 AM, Patrick Brosset <<a href="mailto:pbrosset@mozilla.com">pbrosset@mozilla.com</a>> wrote:<br>
> I just discovered the concept of pre-processors in eslint, I had no idea<br>
> this even existed. Find out more info here:<br>
> <a href="http://eslint.org/docs/developer-guide/working-with-plugins#processors-in-plugins" rel="noreferrer" target="_blank">http://eslint.org/docs/developer-guide/working-with-plugins#processors-in-plugins</a><br>
><br>
> tl;dr;<br>
> We can use this to process our source files before eslint rules are run on<br>
> them.<br>
> So, in particular, we can do things like:<br>
> - filter out ifdef instructions,<br>
> - define global variables from imported modules (from e.g. Cu.import)<br>
<br>
</span>Yeah I've used this to success in bug 1229858 to support linting XBL files<br></blockquote><div><br></div><div>Awesome stuff, I was thinking doing just the same.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
and was thinking along similar lines for an improved head.js<br>
importer for tests (just prefixing the test file with the entire<br>
head.js file).<br></blockquote><div><br></div><div>I agree, this would be a big improvement, especially knowing that the hack we use to import headjs globals into tests scope at the moment is just that, a hack. It's unsupported and might break at any time. In fact it already did a few days ago.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I considered ifdefs a little and I think it might get complicated<br>
fast, you'd probably have to lint the same script multiple times for<br>
each form it can take depending on the ifdefs and if they're nested<br>
that ramps up quickly. Given that we want to drop preprocessing in<br>
general it might be better to just spend the time doing that.<br></blockquote><div><br></div><div>Agreed.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
> On Wed, Dec 2, 2015 at 2:28 AM, Dave Townsend <<a href="mailto:dtownsend@mozilla.com">dtownsend@mozilla.com</a>> wrote:<br>
>><br>
>> On Tue, Dec 1, 2015 at 5:26 PM, Lawrence Mandel <<a href="mailto:lmandel@mozilla.com">lmandel@mozilla.com</a>><br>
>> wrote:<br>
>> > On Tue, Dec 1, 2015 at 1:00 PM, Michael Comella<br>
>> > <<a href="mailto:michael.l.comella@gmail.com">michael.l.comella@gmail.com</a>> wrote:<br>
>> >><br>
>> >> On Sat, Nov 28, 2015 at 7:56 AM, Mark Finkle <<a href="mailto:mfinkle@mozilla.com">mfinkle@mozilla.com</a>><br>
>> >> wrote:<br>
>> >>><br>
>> >>> When I run | mach eslint | I get this error:<br>
>> >>><br>
>> >>> Error: Cannot find module 'eslint-plugin-mozilla'<br>
>> >>><br>
>> >>> How do I get that plugin?<br>
>> >><br>
>> >> I filed a bug to either alert the user to warn this if they haven't<br>
>> >> done<br>
>> >> so already, or to just run it automatically:<br>
>> >>   <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1211483" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=1211483</a><br>
>> >><br>
>> >> Given the sudo issues another person posted, we should warn about that<br>
>> >> too. It'd be great to get some traction on this – it's a confusing<br>
>> >> experience!<br>
>> >>><br>
>> >>><br>
>> >>> On Fri, Nov 27, 2015 at 5:53 PM, Dave Townsend <<a href="mailto:dtownsend@mozilla.com">dtownsend@mozilla.com</a>><br>
>> >>> wrote:<br>
>> >>>><br>
>> >>>> We don't really have automation testing this right now but hopefully<br>
>> >>>> we will soon. For now you can add support to editors like Sublime to<br>
>> >>>> tell you when you're making mistakes:<br>
>> >>>><br>
>> >>>><br>
>> >>>> <a href="https://blog.mozilla.org/standard8/2015/05/13/using-eslint-alongside-the-firefox-hello-code-base-to-help-productivity/" rel="noreferrer" target="_blank">https://blog.mozilla.org/standard8/2015/05/13/using-eslint-alongside-the-firefox-hello-code-base-to-help-productivity/</a><br>
>> >><br>
>> >><br>
>> >> We've had eslint working in mobile for a while but frankly, I don't<br>
>> >> think<br>
>> >> anyone has used it (e.g. we have failures now). I don't think this will<br>
>> >> become truly useful without some automated testing – is there a bug<br>
>> >> open for<br>
>> >> this?<br>
>> ><br>
>> ><br>
>> > I don't know if there's a bug but this type of work is on the list for<br>
>> > MozReview and it should be integrated other places as well. The key is<br>
>> > to<br>
>> > catch regressions like these before they are committed to the tree.<br>
>><br>
>> We definitely want to catch this before it hits the tree but I've also<br>
>> filed <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1229588" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=1229588</a> so we have<br>
>> an in-tree check as well (which would of course work on try). I'm also<br>
>> going to experiment with a hg pre-commit hook that you can install<br>
>> locally.<br>
>> _______________________________________________<br>
>> firefox-dev mailing list<br>
>> <a href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a><br>
>> <a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/firefox-dev</a><br>
><br>
><br>
</div></div></blockquote></div><br></div></div>