incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Reinstein <>
Subject Re: plugin analysis
Date Tue, 02 Oct 2012 18:25:59 GMT
Hey Brian,

> engine attribute in package.json
Maybe I'm wrong but after reading I'm
under the impression this is solely for specifying the required version(s)
of node to use the npm package.

> I do not understand the problem
The problem is before allowing someone to register a plugin, we want to
perform certain checks on the server side that prevent things from blowing
up or corrupting the repo. One very easy thing to check is that the package
identifier a plugin author declares is not collding. I should not be able
to package if it's already used by another package.

> (Lets not solve ones we do not yet have yet
I agree that we should not try to predict every problem that could come up
and solve it up front. I also think that some issues have a nice balance
between being able to check, and being easy to do that them worth doing.
Simple things like verifying plugin.xml is a valid xml doc, that package
names dont collide, etc are very easy to do, and are important to repo

On Tue, Oct 2, 2012 at 2:13 PM, Brian LeRoux <> wrote:

> >    - Cordova plugins depend on specific versions of the cordova library,
> >    and specific versions of xcode, android build tools, and other SDKs.
>  npm
> >    doesnt provide a way to declare those external plugin dependencies, or
> >    query by them.
> Sure it does. engine attribute in package.json (but will require a
> custom couch view which can be authored rather quickly).
> >    - one thing that would really be helpful in the future is to have the
> >    ability to set up rules at the repo publishing point. For example,
> >    preventing someone from publishing a new plugin that re-uses and
> existing
> >    package name ( and doing basic sanity checks that are
> >    specific to our plugin format. Using npm makes this a lot harder.
> I do not understand the problem but I'm certain once there is code we
> could implement a solution. (Lets not solve ones we do not yet have
> too much!)
> >    - npm is intended as a dev tool and package manager for node based
> >    apps/libs. We'd be overloading it's intended behavior by throwing in a
> >    bunch of plugins that are relevant only to the Cordova platform.
> ya its cool, I've talked to the node guys about it. we'll likely run a
> separate federated registry in the future. in issac's own words, 'npm
> is a commons for js'
> >    Having a little discovery portal like that is
> >    specific to our community would be huge.
> thats the vision breaux

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