[Pkg-javascript-devel] roadmap of jquery (and helpers)
Jonas Smedegaard
dr at jones.dk
Sun Sep 18 15:48:44 UTC 2016
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>
More information about the Pkg-javascript-devel
mailing list