Re: Javascript trigger design
Le vendredi 28 novembre 2014 à 06:16 +0000, olivier sallou a écrit :
> 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.
The debian side is in no way able / fit to take care of *live* updating
js/css bundles. This is up to the web framework you're using - like you
mentioned for example RoR.
What is needed for debian-packaged webapps is to be able to regenerate a
bundle made of several other packages files (supporting concatenation,
browserification, whatever else...) when one of them changes at install
time. This requires it knows reverse build-dependencies of the package
that contains the file that changed, and call some trigger of each of
these package so it can itself call the proper script that is specific
for each of these packages.
Jérémy.
Reply to: