How about the globally installed cordova has two things that it knows how to do:
1 - proxy to your local cordova within node_modules (ala grunt-cli) 2 - "cordova create" would execute: mkdir helloworld && cd helloworld && npm init && npm install --save-dev cordova && ./node_modules/cordova create I think the transition from grunt -> grunt-cli was pretty rocky for many people. One thing I think we could do better: have "cordova" remain the globally installed thing. I see two options for this: 1: Make a new npm ID for what is now "cordova" e.g. "cordova-local". 2: (as Michal suggested) Make the existing "cordova" do both things by detecting if it's the globally run one vs the localling installed one. On Tue, Sep 10, 2013 at 5:55 AM, Jesse <purplecabb...@gmail.com> wrote: > cd 3.0 > npm link . > cd .. > cordova -v > > cd 3.1 > npm link . > cd .. > cordova -v > > Very gruntable > > > @purplecabbage > risingj.com > > > On Mon, Sep 9, 2013 at 9:27 PM, Tommy-Carlos Williams <to...@devgeeks.org > >wrote: > > > Or, we could just drop it... and just write a blog post on how to use a > > local cordova vs the global one in projects you want to have a specific > > version (i.e.: some script code example wrapper for a cordova command in > > ./node_modules/.bin/cordova). > > > > 0.o > > > > - tommy > > > > > > > > On 10/09/2013, at 1:42 PM, Michal Mocny <mmo...@chromium.org> wrote: > > > > > An alternative to leveraging npm locally may be to split cli/lib node > > > modules as proposed, but just use the existing .cordova/config.json > file > > to > > > specify the cordova lib location. By default, cordova-cli uses the > > global > > > npm install of cordova-lib, but that could be overwritten just like > > > platform versions. This would also support both a "global lib, upgrade > > all > > > at once" as well as a "local lib, upgrade on demand" workflow. > > > > >
