That's an entirely different thing from scanning or catching things in 
development. That's harvesting from clients in production. That is certainly 
possible, and Wikimedia does that, too.

Deprecated properties[1], and features[2] use mw.track[3] to emit an event.

And the WikimediaEvents extension forwards these to EventLogging (at a sampled 
rate of course). Which are then available privately in the analytics database, 
and made available anonymised in Graphite[5].

You can set up similar logging for JQMIGRATE. Note though that jQuery Migrate 
doesn't have nice keys, you'll have to do with the full descriptive sentence of 
the warning (but you're doing that already at TWN).

You could try something like this:

if ( jQuery.migrateWarnings ) {
 jQuery.migrateWarnings.push = function (msg) {
    mw.twn.log( '/webfiles/jswarning', { msg: '[jquery.migrate]' + msg, stack: 
new Error().stack } );

I might set up some tracking for it at Wikimedia as well, but I'm not sure if 
that'll work properly.

— Krinkle


On 14 May 2014, at 19:07, Siebrand Mazeland <> wrote:

>> Op 14 mei 2014 om 14:58 heeft Krinkle <> het volgende 
>> geschreven:
>> I don't think it is possible or worth the effort to scan for these in an 
>> automated fashion within Jenkins.
>> Static analysis is virtually impossible due to the method names being too 
>> simple, and lots of it relies on details of how methods are called, as well.
> At, we log client side issues using a script[1]. Might 
> something like that be of any benefit?
> [1] 
> --
> Siebrand
> _______________________________________________
> Wikitech-l mailing list

Wikitech-l mailing list

Reply via email to