3:52 a.m.
----- Original Message -----
From: "Lars Uebernickel" <lars(a)uebernic.de>
To: "Development discussion for the Cockpit Project"
<cockpit-devel(a)lists.fedorahosted.org>
Cc: "Martin Betak" <mbetak(a)redhat.com>
Sent: Wednesday, May 18, 2016 11:23:38 PM
Subject: Re: VM Management - initial pull request
Hey,
Wow, great work!
On Wed, May 18, 2016, at 14:16, Marek Libra wrote:
> The Plugin follows ES6 syntax, so Babel has to be used.
We've refrained from using babel so far, because it adds 50 MB to
cockpit's source tarball. (We're shipping all dependencies.)
We'll need to find a solution to this this at some point though, because
react-tools (which we use to transpile jsx) is deprecated in favor of
babel[1].
IIUC, this shipping of both runtime and build dependencies in the tarball is because of
build isolation, so they do not need to download any external library.
If so, a solution to this might be in introduction of "wrapping" rpms containing
a bunch of JS libraries covering multiple project needs. Please have a look at
http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/fc23/x86_64/ovir...
or
http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/fc23/x86_64/ovir...
So we do not need to worry about tarball size and repeatable check of licenses.
> In general, we can see a big benefit in use of webpack for the JavaScript
> in Cockpit.
> Anyway, we tried to keep dependencies on third-party JavaScript
> libraries/tools at minimum and we follow recent Cockpit build
> conventions.
>
> Does it make sense for Cockpit to move to webpack? We want to check
> beforehand whether it's worth of making effort...
Yes, it does. In fact, I'm researching moving the current modules to
webpack right now.
We want to stabilize the API in cockpit.js and allow for external
components. The idea is that components ship whatever libraries they
need in their bundle. This way, we don't need to add all dependencies to
cockpit itself. We only want to promote stuff into the base bundle when
multiple components use it. For example, we might include some commonly
used react components in there at some point.
Would you be ok with waiting for a bit until we have a story for
external modules and then be the first one?
That would be great approach to give each module freedom of choice.
For sure, I'm open to be a pioneer once this is ready, it will certainly untie hands
to all modules.
If the overall comments on the plugin are ok, I will be happy to spend more effort on
ongoing implementation.
So from my perspective, I would prefer to convergate to a merge and stack ongoing smaller
patches on top of it, incl. adaptation to the new "module" approach.
It will assure me in the direction.
>
> Sorry that I don't have comments on the actual component yet ;)
>
> Regards
> Lars
>
> [1]
>
https://facebook.github.io/react/blog/2015/06/12/deprecating-jstransform-...
> _______________________________________________
> cockpit-devel mailing list
> cockpit-devel(a)lists.fedorahosted.org
> https://lists.fedorahosted.org/admin/lists/cockpit-devel@lists.fedorahost...
>