----- Original Message ----- > From: "Lars Uebernickel" <[email protected]> > To: "Development discussion for the Cockpit Project" > <[email protected]> > Cc: "Martin Betak" <[email protected]> > 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/ovirt-engine-nodejs-modules-0.0.7-1.fc23.x86_64.rpm or http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/fc23/x86_64/ovirt-engine-nodejs-4.3.2-1.fc23.x86_64.rpm 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-and-react-tools.html > _______________________________________________ > cockpit-devel mailing list > [email protected] > https://lists.fedorahosted.org/admin/lists/[email protected] > _______________________________________________ cockpit-devel mailing list [email protected] https://lists.fedorahosted.org/admin/lists/[email protected]
