cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Santana <csantan...@gmail.com>
Subject Re: cordova cli global vs. local install
Date Tue, 10 Sep 2013 13:56:27 GMT
Wow! I went to bed and came back too much awesomeness (that's what happens
when you are in the east coast :-) )

Thank you for taking the time to provide feedback and brainstorm around
this topic.

I agree with Michal, I think cordova-cli doesn't fit the use case perfectly
because of bootstrap, cordova creates the empty directory and populates
workspace where grunt already assumes directory&file created
I agree with Tommy to many commands to get started. and thanks for the tip
of using npm link that could be use in the blog also

I will continue brainstorm maybe there is a solution outside cordova, maybe
some type of bootstrapping with template/scaffolding or "cordova init"

But from the discussion I think there are some good outcomes that I like:

*+1 Write a blog post about using cordova locally*
     The scenario (having one build server that runs cordova builds for
different teams/apps, not all teams might want to share same cordova cli
and its dependencies)
     Global requirements: Only node and npm install globally
     Installing with npm locally
     Running the local version (./node_modules/.bin/cordova or
./node_modules/cordova)
     Using npm link or modifying $PATH
     Checking into source control local node_modules/ including cordova cli
and its dependencies
           (http://www.futurealoof.com/posts/nodemodules-in-git.html) "Only
checkin node_modules for applications you deploy, not reusable packages you
maintain."
     etc...

*+1 Version detection for cli tool*
    cordova and plugman to inform the user that a new version of the tool
is available
[Bower] (http://bower.io) does something similar:
exp5:$ ./node_modules/.bin/bower install jquery
-----------------------------------------
Update available: 1.2.6 (current: 1.2.5)
Run npm update -g bower to update
-----------------------------------------
[image: Inline image 1]

*+1 I'm adding this one "version reporting for platforms and plugins"*
What about reporting the versions of the platforms and the plugins?

Today I only get a list of them but it doesn't let me know what version are
installed or check if a new version is available for plugin or platform.
Reporting what's install should be a good start


myHybridAppFolder:(master)$ cordova platforms
Installed platforms: android, ios
Available platforms: blackberry10
myHybridAppFolder:(master)$ cordova plugins
[ 'org.apache.cordova.core.device',
  'org.apache.cordova.core.device-orientation',
  'org.apache.cordova.core.dialogs',
  'org.apache.cordova.core.file',
  'org.apache.cordova.core.geolocation',
  'org.apache.cordova.core.globalization',
  'org.apache.cordova.core.inappbrowser',
  'org.apache.cordova.core.media-capture',
  'org.apache.cordova.core.network-information',
  'org.apache.cordova.core.vibration' ]
myHybridAppFolder:(master)$






On Tue, Sep 10, 2013 at 5:55 AM, Jesse <purplecabbage@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 <tommy@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 <mmocny@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.
> >
> >
>



-- 
Carlos Santana
<csantana23@gmail.com>

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