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.
On Wed, Oct 18, 2017 at 2:21 PM Dan Mosedale <dmosed...@mozilla.com> wrote: > 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. > > Dan > 2017-10-18 9:06 GMT-07:00 Dave Townsend <dtowns...@mozilla.com>: > >> On Wed, Oct 18, 2017 at 4:51 AM Mark Banner <mban...@mozilla.com> wrote: >> >>> 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. >>> >>> 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. >>> >> >> 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. >> >> >> _______________________________________________ >> firefox-dev mailing list >> firefox-...@mozilla.org >> https://mail.mozilla.org/listinfo/firefox-dev >> >> _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
