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]. > 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? 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]
