<div dir="ltr"><div>I'm wary when it comes to code that lives in tree as it's both an added thing for contributors to learn and an added build step for that code. Also by doing it only within a module you end up missing out on a bunch of benefits. For system add-ons that live elsewhere though I think that is up to the developers of that add-on to decide what they want to do bearing in mind they'll be adding a build step as part of getting their code into m-c.</div><div><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 18, 2017 at 2:21 PM Dan Mosedale <<a href="mailto:dmosedale@mozilla.com">dmosedale@mozilla.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-size:small">Dave, how would you feel about deciding on one of those and allowing modules to opt-in to using them, perhaps just as an experiment. Presumably most existing modules wouldn't, but new ones being written might.</div></div><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Dan<br></div></div><div class="gmail_extra"><div class="gmail_quote">2017-10-18 9:06 GMT-07:00 Dave Townsend <span dir="ltr"><<a href="mailto:dtownsend@mozilla.com" target="_blank">dtownsend@mozilla.com</a>></span>:<br></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span>On Wed, Oct 18, 2017 at 4:51 AM Mark Banner <<a href="mailto:mbanner@mozilla.com" target="_blank">mbanner@mozilla.com</a>> wrote:<br>
</span><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><blockquote type="cite">
<pre>I remember that we had bugs of this kind lurking for years in our
codebase, in code that was triggered daily and that everybody believed
to be tested.
I'd like to think that there is a better way to handle these bugs,
without waiting for them to explode in our user's face. Opening this
thread to see if we can find a way to somehow "solve" these bugs, either
by making them impossible, or by making them much easier to solve.</pre>
</blockquote></div><div text="#000000" bgcolor="#FFFFFF">
ESLint has caught some bugs - mainly undefined and unused related
issues, and is spread through most of the production javascript
code. Unfortunately it isn't able to catch this class of error. For
that, we'd need something like Flow. Last time I looked at it, it
didn't feel like a good fit for us, although I didn't go too deep,
and I think there may have been other people that were looking at
it.</div></blockquote><div><br></div></span><div>As a datapoint, I've looked at both Flow and TypeScript. Both are good tools that work well if you're writing code from scratch with them but for existing code they flag many many pre-existing problems, the vast majority of which aren't really problems just cases where the tools can't infer what is going on without adding type info to the script. I came to the conclusion that it would be too much work to use either in our main codebase.<br></div><div> </div></div></div>
<br></blockquote></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">_______________________________________________<br>
firefox-dev mailing list<br>
<a href="mailto:firefox-dev@mozilla.org" target="_blank">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></blockquote></div></div></blockquote></div></div></div>