> there's a lot of stuff going on in that link. certainly, happy to do that:
- would cordova specific code blobs being packaged as npm modules pollute npm? an illustrative scenario: I go on npmjs.org right now and browse the packages. It's like xmas; I see all these awesome modules that I can use in any node app that I build. Fast foward to a future where hundreds of cordova plugins are in npm. Joe user is browsing packages to pull into his super awesome node based app. He's never heard of cordova or doesnt use it. He keeps running into these modules that reference cordova, and are utterly useless by themselves, because its meant to work with this whole other platform. Suddenly there are modules in npm that have nothing to do with writing packages that work in the node ecosystem. These modules arent truly modules because they dont expose an API that makes it re-usable as an atomic unit of code. - 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. - the install process for one of these plugins is very different from a typical npm module. the install code has a bunch of logic to move the bits of each plugin into the build environment in existing projects in xcode ios, android projects, etc. Not sure if npm provides some kind of install hooks to modify this behavior, I would assume its rigidly following node_modules as the destination for all installed modules. - without going too much into cordova plugin internals, the package file for a cordova plugin is an XML file (aptly named plugin.xml.) We've considered JSON vs XML for the plugin's manifest format, but because many of the install steps involve grafting/pruning XML tags in configuration files, JSON seems like a poor way to represent these chunks of xml to operate on. So if we use npm's package.json, we'd need to maintain that, and the plugin.xml. Maybe there is an elegant way to store XML blocks in JSON, which means we could do away with using XML as our main format, but it's unclear to me at this point the best course of action. having to maintain some data that is identical between package.json and plugin.xml just feels bad, bad, bad. - 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. - 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. > we've been discussing pkg mgmt for 3 years I understand the sense of urgency; I'm sure after a while it's like "f* it let's just build something". :) I'm not suggesting we launch into a 6 month academic discussion of perfect plugin distribution. I think with a few days of back and forth we were really productive on pluginstall and it's lower level pieces, and got some really great changes into a common place. I'm hoping for similar results here. :) -Mike On Sun, Oct 14, 2012 at 8:28 PM, Brian LeRoux <b...@brian.io> wrote: > Eh mike, could you just briefly write out the bullets? ....there's a > lot of stuff going on in that link. =) > > FWIW, we've been discussing pkg mgmt for 3 years which may be why most > of us lean to prototyping fast at this point. I feel node/issac has > solved the issue best of all the solutions I've personally > investigated and happy to comment specifically on any concerns you > have. > > > On Sun, Oct 14, 2012 at 5:17 PM, Mike Reinstein > <reinstein.m...@gmail.com> wrote: > > What I'm worried about is trying to do a top-down design on a package > > manager without looking at the underpinnings. I really don't care _how_ > > the problems are solved. I don't think my registry toy solves the issues, > > nor does the solely npm based solution. It's a big mistake to > definitively > > choose how we should package and distribute plugins without discussing > the > > issues we've identified at a low level. > > > > The issues that I've brought up are in the bullets in this post: > > https://github.com/dominictarr/rc/issues/5 > > > > Does anyone have feedback on these? > > > > -Mike > > > > > > On Sun, Oct 14, 2012 at 7:58 PM, Brian LeRoux <b...@brian.io> wrote: > > > >> I'm in the 'reuse npm as a dependency' camp. We can override stuff > >> that way and not get stuck re-implementing the entire thing. > >> > >> Just look at the size of Max's proposal as a result.Less code to > >> write, means less to test, and ultimately less to maintain. > >> > >> That said, I encourage we code for all the things and see what suites us > >> best. > >> > >> > >> On Sun, Oct 14, 2012 at 12:11 PM, Mike Reinstein > >> <reinstein.m...@gmail.com> wrote: > >> > Hi Max! > >> > > >> > We've been chatting about package manager stuff a bit prior to your > >> arrival > >> > a few days ago. The 2 main proposals we've seen are to use npm for > >> > everything, or try to set up an independant system, which is similar > but > >> > different (hopefully suited to cordova's particulars.) I've been > >> exploring > >> > option 2, and had a brief discussion with Isaac Schlueter and Dominic > >> about > >> > this. I think it's an interesting read. > >> > https://github.com/dominictarr/rc/issues/5 > >> > > >> > Here is the spec (and partial implementation) of what I've got so far: > >> > https://github.com/mreinstein/cpm > >> > > >> > I would really appreciate some feedback on this. If it turns out that > the > >> > cordova community is really against doing it this way then I'd rather > >> know > >> > sooner than later, so I'm not burning time on a project that no one > >> wants. > >> > I'm hoping for more feedback from Isaac as well, especially on the > >> bullets > >> > in that rc discussion because I think I outlined all the major hurdles > >> that > >> > using npm straight up might introduce. In my opinion, using npm > directly > >> > would be a mistake, but I'm still in the experimentation phase at this > >> > point. > >> > > >> > -Mike > >> > > >> > > >> > On Sun, Oct 14, 2012 at 8:27 AM, Max Ogden <m...@maxogden.com> wrote: > >> > > >> >> meet lunny > >> >> > >> >> https://github.com/maxogden/lunny > >> >> > >> >> lunny is about 60 lines of code: > >> >> https://github.com/maxogden/lunny/blob/master/lib/lunny.js > >> >> > >> >> the basic idea is: > >> >> > >> >> 1. use npm for pretty much everything > >> >> 2. if a package has some special metadata in its package.json then > lunny > >> >> will run plugin-install with the proper arguments > >> >> 3. there is no step 3! > >> >> > >> >> right now the hardest part about publishing and distributing a > cordova > >> >> package is authoring the plugin.xml file so I have only tested this > with > >> >> the childbrowser plugin from http://github.com/alunny/childbrowser > >> >> > >> >> thoughts welcome! > >> >> > >> >
