[Pkg-javascript-devel] roadmap of jquery (and helpers)

[Jonas Smedegaard]

Quoting Paul Gevers (2016-09-18 09:40:30)
> On 09/17/16 10:51, Jonas Smedegaard wrote:
>> Quoting Paul Gevers (2016-09-16 20:01:27)
>>> How are other JavaScript chains handling the lack of automatic API 
>>> tracking?
>>
>> At least 16 packages unacceptably violates Debian Policy, according 
>> to 
>> https://anonscm.debian.org/viewvc/secure-testing/data/embedded-code-copies?view=co
>
> This was not what I meant. What I meant is how JavaScript is handling 
> the lack of shlibs/symbols processing as we do during package building 
> for libraries and depending packages. I would love to know how I can 
> learn what version of $javascript-package I actually need for my 
> package to work properly.

Oh - sorry for not reading properly what you indeed explicitly wrote!

I am unaware of any systematic checks being done to javascript packages 
like the symbols files we have for C/C++ libraries.

Would be awesome to improve on that!  The "scope analyzer" part of 
UglifyJS might be a start: http://lisperator.net/uglifyjs/scope

I don't know javascript well enough to program something myself, though.


>>> Are there tools in the team to check for breakage? One of the stupid 
>>> but powerful things that I do for the cacti package (a web-app) is 
>>> to just recursively crawl all web-pages, I guess it must be possible 
>>> to also check JavaScript execution.
>>
>> In theory we have several tools to emulate javascript-enabled 
>> browsing,
>
> Could you please hint which ones you have in mind?

Backbone used to use PhantomJS in its upstream testsuite.  The testsuite 
as a whole required parts not packaged for Debian but I had lifted out 
the one line executing PhantomJS.  But then PhantomJS had problems close 
to a freeze and I avoided PhantomJS (see bug#768754).

Recently when upgrading Backbone, I had a look at that PhantomJS issue 
again, but failed for me to use xvfb (workaround noted in bug#817277).

There are some alternatives to PhantomJS, and there are verious 
frameworks making use of either PhantomJS or some of its alternatives.

http://stackoverflow.com/questions/14964108/alternative-to-phantomjs-for-testing 
mentions some alternatives, one of them being "jsdom" seemingly what we 
have in Debian as node-jsdom, but I gave up on trying to figure out how 
to use it.

Backbone recently switched upstreeam to the helper tool 
https://github.com/karma-runner/karma - which at its website mentions a 
range of related helper tools, some of which might (directly or 
indirectly) support either PhantomJS or some alternatives.

Another approach might be to sidestep the whole Nodejs environment for 
testing.  Seems there are automated web browsing testing tools for java, 
python and perl - where "Selenium" pops up frequently as a protocol(?) 
commonly used...

I am a perl guy mostly.  If you are a python guy you might have more or 
different options available...


>> I guess locally - *not* using Debian infrastructure - one might use 
>> npm
>
> Why not using Debian infrastructure, because one needs to download 
> stuff that isn't in the package? I was thinking of running these tests 
> as autopkgtest?

Correct: Many tools used in upstream testsuites are not packaged in 
Debian yet.

I don't know the rules for autopkgtest - if pulling in alien code then I 
guess that is an option - but IMO would be a severe bug in the rules for 
autopkgtest (but arguably that's besides the point of this discussion).


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/attachments/20160918/b8febc70/attachment.sig>