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
signature.asc
Description: signature
-- Pkg-javascript-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
