cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <>
Subject Re: [cordova-js] do we need <clobbers/>, <merges/> ?
Date Thu, 10 Apr 2014 15:18:48 GMT
Alright, this thread is starting to run away, I think.

We have a G+ Hangout scheduled for next week.  This looks like a great
topic to discuss.  Generally, I think we should resolve these disputes the
only way that makes real sense: produce a set of test cases that work today
and that we want to continue to work after this change and hand them over
to Anis/Brian.  That way we can be tangible with our arguments.  We'll do
that from our end in prep for next week.

(I think some of the friction here comes because this isn't seen as a pain
point / priority, and so aversion to change kicks in.  However, Anis/Brian
seem excited about it and have put in the leg work, and that certainly
meets my bar for acceptance.)

So, lets leave the discussion for next Tuesday at the Hangout.  Come with
use cases.


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

> On Wed Apr 9 08:40 PM, Brian LeRoux wrote:
> >
> > 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.)
> I put up an example here:
> The cons were against the current plugin.xml & <clobbers/>, <merges/>
> To be clear, it's a pro for using something like browserify.
> If part of the net benefit is we can have a story like:
> cordova create plugin file.encrypt
> Extend existing plugin:
> cordova plugin test <--- this (runs in some bleeding edge browser)
> That's a big win / net benefit for being more opiniated about the module
> format.
> The browserify node.js story looks like:
> But trying to bring the entire node.js api *into* the browser is a big
> hack, turning an apple into an orange.

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