Le 07/11/2014 21:32, Erik Rose a écrit :
For analyzing Firefox's internal JS (which is what we're trying to do
in DXR), it's not suitable, since Spidermonkey went off in all sorts
of non-standardized directions, and no off-the-shelf tool supports ES6
yet, let alone our pre-standardization dalliances.
But for a service checking browser compatibility for web content, that
shouldn't be a concern.
Can anyone who works on Firefox say whether we're headed toward ES6
conformance internally and, if so, what the timeline might be?
I do not work on Firefox, but know a couple of relevant bugs
https://bugzilla.mozilla.org/show_bug.cgi?id=867609
https://bugzilla.mozilla.org/show_bug.cgi?id=867617
I think Firefox aims at removing all deviations from ES6.
https://bugzilla.mozilla.org/show_bug.cgi?id=611388
https://bugzilla.mozilla.org/show_bug.cgi?id=1001090
were important steps in that direction, for instance.
I haven't heard of a timeline. Among other reasons, changing the
semantics of chrome-level JS bears a compatibility risk for addons, so
that'll all take time and it'd be hard for anyone to tell how long.
David
Cheers,
Erik
On Nov 7, 2014, at 14:55 , Luke Crouch <[email protected]
<mailto:[email protected]>> wrote:
Thanks David, that's very helpful.
I'm adding dev-static-analysis to this to see if anyone on that list
(Erik maybe?) has any ideas on this.
In short, we're learning that JS will certainly be the most challenging
language for which to create a compatibility linter/scanner. ;)
-L
On 11/7/14 10:18 AM, David Bruant wrote:
Le 07/11/2014 16:42, Luke Crouch a écrit :
+Justin
Thanks for the info David, sorry you coudn't make it.
In addition to the updated notes in the etherpad [1], Justin and I met
[2] with Thijs Busser who createdhttp://jscc.info/that mashes up data
from Kangax & Can I Use with a bunch of regexs.
He mentioned wanting to useesprima.org <http://esprima.org/>? Do
you like that approach too?
Totally. Anything that relies on regexps to do anything with code is
doomed to fail at some point. AST-based analysis are the way to go
(fundamentally, code as a data structure is a trees and regexps cannot
work on trees).
And esprima is the state-of-the-art JS parser that lots of static
analysis tools are based on (escodegen, eslint, etc. The list of
dependent tools on npm is sayinghttps://www.npmjs.org/package/esprima
). Esprima is fully ES5-compatible and they're actively working on an
ES6 branch (harmony), so that would be the parser I'd bet on.
But in my opinion, it still won't be enough. A naive tool based on
esprima won't be able to understand that the following is not
browser-compatible (yet, because Object.assign is introduced in ES6):
----
var O = Object;
var assign = O.assign;
assign({}, {});
----
(and some forms of this will occur in real-life code, because on the
web, everything happens)
To understand that this code is not ES5 compatible, one has to track
that the O variable has such type (and such static functions attached to
it), etc. and that's tedious work. The good news is that it's exactly
the sort of work the TypeScript compiler was designed to do.
Other compiler like the Closure Compiler do this kind of work too, but
they force you into writing your JavaScript in a particular style (in
order to make the code more easliy analysable). The reason I'm so fan of
TypeScript is that they've found a great balance of analysing types in
JS while letting authors write their code in whatever style fits them.
Hope that helps,
David
Thanks,
-L
[1]https://etherpad.mozilla.org/compat-data-for-static-analysis
[2]https://devengage.etherpad.mozilla.org/jscc-mdn
On 11/7/14 8:58 AM, David Bruant wrote:
Hi Luke,
I'm very sorry, I couldn't attend the meeting. I was catching up after
MozFest.
As far as JavaScript static analysis is concerned, I'm sure there is a
"quick" win to be won hacking the TypeScript compiler (especially now
that they've re-written it entirely and that it's apparently much
cleaner).
Tools like JSLint/JSHint/ESLint (3rd is my favorite because of its
very
modular rule architecture) can verify some aspects of a program,
but are
really syntax-based. For instance, these tools cannot tell whether
you're using setTimeout with a string or a function as first argument.
On the other hand, TypeScript can and does and you can be sure it
does,
because that's what it's been written for (track types across
variables
and function arguments).
TypeScript is initialized with a declaration file so that the compiler
knows about the "standard library" (functions exposed per ECMA and W3C
specs). I'm sure it would be easy to change these declaration files to
see if some code is using non-standard and/or edgy (or prefixed)
functions in their code.
rhaa... I'm babbling and it's complicated to explain in an email.
If you're interested, maybe we can call some time next week so I
explain
all that (unless it's too early-stage discussion in which case, we can
postpone to a more appropriate time).
David
Le 27/10/2014 18:32,[email protected]
<mailto:[email protected]>a écrit :
The following is a new meeting request:
Subject: Web Compat Service & Static Analysis
Organizer: [email protected]
<mailto:[email protected]>
Sent By: "Luke Crouch" <[email protected]
<mailto:[email protected]>>
Location: VidyoRoom - Luke Crouch
Time: Wednesday, October 29, 2014, 11:00:00 AM - 12:00:00 PM GMT
-06:00 US/Canada Central
Invitees: [email protected]
<mailto:[email protected]>; [email protected]
<mailto:[email protected]>;
[email protected] <mailto:[email protected]>;
[email protected] <mailto:[email protected]>;
[email protected] <mailto:[email protected]>;
[email protected] <mailto:[email protected]>
*~*~*~*~*~*~*~*~*~*
Vidyo: Luke Crouch
Room Link:
https://v.mozilla.com/flex.html?roomdirect.html&key=k3IKWMEdaAsz
Webcast Link:
https://vreplay.mozilla.com/replay/webcastShow.html?key=SbB5sPpfCaIQ8b8
Dial-In: 1-650-903-0800, x92; Conference #: 99163
+1 800 707 2533, pin 369; Conference #: 99163
IRC: #mdndev
Agenda: https://etherpad.mozilla.org/compat-data-for-static-analysis
--
Q: Why is this email five sentences or less?
A:http://five.sentenc.es <http://five.sentenc.es/>
_______________________________________________
dev-static-analysis mailing list
[email protected]
<mailto:[email protected]>
https://lists.mozilla.org/listinfo/dev-static-analysis
_______________________________________________
dev-static-analysis mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-static-analysis
