On 26.11.2015 01:57, Andrew Sutherland wrote: > On Wed, Nov 25, 2015, at 04:43 PM, Jim Porter wrote: >> I'm less sympathetic to the fact that it would break our >> linter, but that's probably because I think linters are a bit silly to >> begin with; if you want good build-time checks that your code isn't >> totally broken, you should use a compiled language and compile with >> -Wall -Werror. :) > > It's important to call out that eslint has transcended pure syntactic > linting and is now also a very important lightweight static analysis > tool that does more than avoid stylistic review nits. While jslint and > maybe jshint were more biased towards finding nit-only problems, eslint > finds and detects both obvious and subtle bugs in the language that > we're writing everything in. > > For example, :freddyb's > https://github.com/mozfreddyb/eslint-plugin-no-unsafe-innerhtml detects > potentially unsafe uses of innerHTML. And these frequently aren't > nuisance warnings[1]. The music app NGA rewrite on > https://bugzilla.mozilla.org/show_bug.cgi?id=1208154 (reviewed by you ;) > introduced a real violation intentionally whitelsited in xfail.list that > I manually encountered while code-reading and was filed and fixed as > https://bugzilla.mozilla.org/show_bug.cgi?id=1209210.
There is little for me to add here besides that we will continue using these tools and gradually introduce additional tools for similar mistakes (i.e. easy to spot, easy to mitigate). Whatever preprocessor we end up with, we must retain the ability to detect and prevent security issues as early as possible. _______________________________________________ dev-fxos mailing list dev-fxos@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-fxos
