On Fri, Mar 14, 2014 at 7:13 AM, Braden Shepherdson <[email protected]>wrote:
> Cordova platforms don't map into Cordova plugins very well at all. > No, they don't indeed. It would be really interesting to `plugin add` a platform. > > For npm modules, we can specify arbitrary sources, but npm has its own > ideas about where things should be installed. Do we actually want the > platforms, or at least their templates, to live in node_modules? I suppose > that's a reasonable flow. > > 1. Lazy load. Formerly via git into a cache dir in $HOME, now via npm into > $PROJECT/node_modules/cordova-foo. > 2. Same as before: Run the platform's bin/create script to install an > instance of the platform in $PROJECT/platforms/foo. > > That should be drop-in-able. But I don't know how well our collections of > non-JS files will fit into npm. It's not really intended for this sort of > thing. > Yes, that is why I like this solution. We also remove our dependency on git for CLI. There are a lot of non javascript-only modules on NPM. Some Javascript modules rely on native components (usually built with node-gyp). We wouldn't need to do that as we would be be basically using npm as a storage solution alternative to git. We also still get to keep to ability to version platforms (as opposed to tags etc...). As a side note, I've published cordova-js to npm as well because I need it for my current browserify efforts. I will explain why in another thread. > > Braden > > > On Fri, Mar 14, 2014 at 9:19 AM, David Kemp <[email protected]> wrote: > > > +1 to handling both the same way and not using git for distribution. > > > > I'm interested in the pros and cons of using the plugin registry vs npm. > > > > > > > > On Thu, Mar 13, 2014 at 10:14 PM, Gorkem Ercan <[email protected] > > >wrote: > > > > > Great idea.. I especially don't like the git archive download. It does > > not > > > really allow us to track some sort of statistics reliably. I think its > > > replacement should allow collection of download statistics. The plugins > > > stats from plugman seems OK. I am not sure if npm would allow such > stats. > > > > > > Not that important to this discussion but I think plugman has a cache > in > > > .plugman/cache > > > > > > -- > > > Gorkem > > > > > > > > > On Thu, Mar 13, 2014 at 11:25 AM, Andrew Grieve <[email protected] > > > >wrote: > > > > > > > Right now, CLI downloads & caches platforms & plugins using two > > different > > > > mechanisms, with totally independent code paths. > > > > > > > > plugman uses the request library, with proxy settings in > > .plugman/config. > > > > It downloads the tars directly from registry.cordova.io. It does not > > > cache > > > > them. > > > > > > > > CLI uses the request library as well, with proxy settings from > .npmrc. > > It > > > > downloads tars directly from our git server's archive endpoint. It > > caches > > > > them in ~/.cordova. > > > > > > > > > > > > I'd like to propose that we unify them. Specifically: > > > > > > > > 1. Store platforms on registry.cordova.io > > > > - This would allow CLI to easily see what versions of platforms are > > > > available, and be able to choose between them. > > > > - This (I'm sure), INFRA would be much happier about than our > current > > > > fetch-from-git approach > > > > > > > > 2. Unify CLI & Plugman's downloading logic > > > > - Use the same code-path for both. > > > > - Have them use the same caching logic. > > > > > > > > 3. Use npm's cache logic instead of our own: > > > > - Just type npm help cache to see what it does > > > > - Would allow for: "cordova cache clean" > > > > > > > > I would *not* want to lose our support for --searchpath, as I think > > it's > > > > really handy. I don't see a problem with this though. > > > > > > > > This would also enable CLI to answer queries like "what platform > > versions > > > > are available", and make it trivial to do "install > > [email protected] > > > " > > > > > > > > This isn't something I have time to work on in the near future, but > > > wanted > > > > to see if everyone would be onboard with the change. I'll end up just > > > > filing bugs for the changes if it sounds good... but if anyone else > > wants > > > > to work on it... :) > > > > > > > > > >
