Hi
On Tue, May 23, 2017 at 2:45 PM, Joao Pedro De Almeida Pereira
<jdealmeidapereira@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