Hi On Tue, May 23, 2017 at 2:45 PM, Joao Pedro De Almeida Pereira <jdealmeidapere...@pivotal.io> wrote: > Hello > > >>> I wrote few grunt tasks using r.js optimizer this weekend > > How did it compare to webpack? > >> I am already starting to wonder if Grunt is the best way to do this >> though. It might be easier (though not quite as efficient) to have the >> Python module all return their static/template JS code at initialisation, >> effectively dynamically building a single packed file containing nearly >> everything. > > We could. Are you saying that the app should bundle js every run? To be > fair, this is what we're currently doing with Grunt, but it feels like we > should change this for non-development use.
For every non-debug run, it should check for changes in files, perhaps by comparing the mtime of the packed file against all of the files it would contain. However, that begs the question of what happens in an installed instance, where the user running it likely doesn't have permissions to re-pack the files if they're in the installation directory. Perhaps packing should be done into a temp directory for each user? For debug runs, it should use the unpacked files in each module. >> Yeah, though I think there are more considerations we haven't yet thought >> of. > > Something we aren't clear on is the end-user use case of dropping modules > into existing installations. Is this achieved via installer? That's the intention, yes. It could be that the installer would re-pack everything by calling a script we can supply, or the mechanism I suggested above could handle it on next launch. I'm actually thinking that maybe it would be easier to start with the CSS files.... -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
