cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian>
Subject Re: a package manager experiment
Date Mon, 15 Oct 2012 01:30:56 GMT
>    - would cordova specific code blobs being packaged as npm modules
>    pollute npm?

We have 100 modules. There are far worse in the registry than even our
100. Issac is totally cool w/ us doing this and given the alternatives
I think its the right thing to do.

Keeping in mind npm registry is federated so none of this matters. We
can move. We probably will. Maybe when we get to 200 plugins.

>    - plugins are intrinsically tied to specific development platforms and
>    SDKs. Is there a way in npm to say "this module depends on Android SDK
>    0.3.x, 0.4.2, and cordova 0.2.x ? There's been talk in our mailing list of
>    using the engines tag in package.json but I'm under the impression that
>    it's soon to be deprecated.

deprecated by npm != deprecated by us. we can still read JSON. Shit,
we can even add our own keys/values. we can also send pull requests to

>    - the install process for one of these plugins is very different from a
>    typical npm module.

Sure. We will have to write some code. =)

>    - without going too much into cordova plugin internals, the package file
>    for a cordova plugin is an XML file (aptly named plugin.xml.)

Gonna go w/ Jesse on this one. A manifest for plugins install/remove
(plugin.xml) and a separate manifest for discovery (package.json).
Best tools for the respective jobs at hand. Kinda gross in our package
format but this project is completely bereft of conceptual purity
anyhow. ;)

>    - cordova plugins ideally have a form of plugin resolution at the
>    publish step. So for example in the NFC plugin, it should have a unique
>    java package style identifier likeio.cordova.nearfieldcomm The registry
>    should be able to detect this, and enforce uniqueness to prevent collisions
>    with other plugins.

npm / npm registry does this ya.

>    - There are other forms of collisions that would be checked for. e.g,
>    when building plugins for the ios platform, classnames exists in the same
>    namespace, so there should be a way to ensure classnames aren't colliding.

sure, package validation is definitely a feature of install/remove...

View raw message