cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian>
Subject Re: [cordova-js] do we need <clobbers/>, <merges/> ?
Date Thu, 10 Apr 2014 00:40:16 GMT
As they say: patches welcome. We didn't just pick Browserify without
thinking this through: with code. From my perspective using an external
tool focused on the problem that is battle hardened is better than
maintaining our own and Browserify is the best of the bunch.

I don't care if it has many dependencies so long as it itself is tested
well. Agree, ES6 modules would be great but that is not happening anytime
soon for the mobile web. Webpack solves the problem without having an
opinion, a great deal of optional config, making it fragile (imo). I'm not
a fan requirejs (or indeed amd in general) for cases wherein we just concat
to a single file and load it once anyhow negating its only promise.

The cons are wrong. You can import plugins and indeed you can test plugins.
The statement that we shouldn't need to compile/transpile is not correct if
we want to evolve things. Its the only path we have that will keep things
backwards compatible. (That we could determine.) Again, we welcome a branch
that demonstrates alternatives.

On Thu, Apr 10, 2014 at 9:55 AM, Jonathan Bond-Caron <> wrote:

> On Tue Apr 8 03:50 PM, Andrew Grieve wrote:
> >
> > The question of whether we *need* them is not a good way to phrase it I
> think.
> > Rather:
> > Pros?
> - Cordova doesn't pick a style of writing modules/plugins
> - More control over how plugin loading works
> Prefer this approach for now, might be a better way to do this eventually:
> Good points by Alex Young, James Burke
> > Cons?
> - No way to require() or import() other plugins, e.g. extend a plugin
> - Difficult to "test" cordova plugins
> - Shouldn't need to compile/transform/transpile a plugin to test it
> > Worth changing at this point?
> Not a fan of any 'bundling' tool with so many dependencies:
> The ES6 web modules situation is evolving, but still messy:
> Seems better to experiment more

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message