[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Javascript trigger design





Le Fri Nov 28 2014 at 01:55:26, Tomas Pospisek <tpo2@sourcepole.ch> a écrit :
Am 28.11.2014 um 00:04 schrieb Thomas Goirand:
> Hi,
>
> Web application have evolved into monsters that needs lots of
> _javascript_. It's very common that these _javascript_ applications are
> collecting all the .js library they use, concatenate them into a single
> file, and compress the result using all sorts of tools (node uglify is
> one of the implementation, but that's not the only one).
>
> As much as possible, as good Debian citizens, we do package each and
> every _javascript_ library into a separate package. But then, if there's
> an update of that JS library, the Web application package has to somehow
> know about it, and redo the concatenate & compress job. Otherwise, the
> web app would continue to use the old version.
>
> I have this issue with the OpenStack dashboard (ie: Horizon), but also
> with a second web app which I'm currently packaging (OpenStack Fuel,
> which is a deployment software for OpenStack). Though this could of
> course be generalize to any JS app.
>
> It's been a long time I've been thinking about it, and I believe that
> the only way to do this, would be to use triggers. Though I have never
> used triggers, and I thought it was a good idea to ask my DD friends and
> this list about it. Should there be one trigger per web app? How would
> this work?
>
> Thoughts anyone? Jonas maybe, who did lots of JS packaging?

At least the Ruby On Rails framework notices an updated JS and will
re-compress the whole JS blob from its parts. I don't know about other
server side frameworks, but they _should_ be able to do the same. - ?
Unfortunalty no. Many "frameworks" help you build such things but with no update detection. Many frameworks are not running server like RoR but only build tools (Grunt, Yeoman, ...)
These tools concat/minify/uglify etc... at build time and then you just put your app under Apache/Nginx and a different language server (to manage the GUI).
So there is no awy for all these tools to detect a change and automatically do the modification.

1) A trigger mechanism could indeed inform an additional script (that Debian developper/maintainer should develop per app) and this script could do the job, but on "production" system, I do not think that you would want to do automatically this because this may imply other things, and/or many compilation on your server at the same time (think of a jquery update triggering update of all dependent platforms...).

2) One thing could be that a dependency update triggers a rebuilt of the package with a kinda automatic minor version upgrade.... and you would benefit from it at next system/app update.

From a deveopper point of view (which I am), I would like idea 1, but from an admin point of view I think it would be idea 2.


Olivier

 
Or
there shoould be some switch or some additional plugin or such that
enables the same functionality.

Or do I missunderstand you?
*t


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: [🔎] 5477C7B4.90703@sourcepole.ch" target="_blank">https://lists.debian.org/[🔎] 5477C7B4.90703@sourcepole.ch


Reply to: