W3C home > Mailing lists > Public > spec-prod@w3.org > July to September 2012

Re: biblio.js update best practice?

From: Robin Berjon <robin@w3.org>
Date: Tue, 25 Sep 2012 18:16:46 +0200
Message-ID: <5061D8EE.4000801@w3.org>
To: Marcos Caceres <w3c@marcosc.com>
CC: Frederick.Hirsch@nokia.com, spec-prod@w3.org
On 25/09/2012 16:17 , Marcos Caceres wrote:
> On Tuesday, September 25, 2012 at 11:00 AM, Robin Berjon wrote:
>> On 24/09/2012 19:22 , Frederick.Hirsch@nokia.com
>> (mailto:Frederick.Hirsch@nokia.com) wrote:
>>> What is the best way to test a change to biblio.js before pulling
>>> it into the main build?
>>
>> In general I only do the most cursory test of biblio.js: I check
>> the syntax. For that, I just do node bibrefs/biblio.js. If it
>> doesn't blow up then the syntax is fine.
>
> By blow up, I assume Robin means

Sorry if I was unclear — I replied to two emails from Frederick in a row 
and didn't notice that only one of them had spec-prod as a Cc.

> (in some javascript console, like
> Chrome's dev tools):
>
> var x = {"ID" : "the citation"}; x["ID"]; //returns what is expected
>
> Throws no syntax errors. That's the easiest way to check.

To put the issue in context, biblio.js is the most edited file by any 
metric, and by far the one with the most contributors. It's also the 
most painful to edit. This leads to the occasional (but in effect rather 
rare — IIRC the last one was in 2010) bug in it that breaks all of ReSpec.

So Frederick was asking how to check it when he makes a change, without 
having to go through making a complete build. The simplest way I know is 
to just execute it in NodeJS (or any other CLI JS interpreter). If you 
get no message back, then it's fine and you can push.

You can also, as you say, have it be loaded in the browser — but that's 
more work :)

-- 
Robin Berjon - http://berjon.com/ - @robinberjon
Received on Tuesday, 25 September 2012 16:17:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 25 September 2012 16:17:04 GMT