You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Carlos Santana <cs...@gmail.com> on 2013/09/09 17:48:03 UTC
cordova cli global vs. local install
What does the community think of installing cordova only locally and not
globally?
# Installing Cordova locally will provide:
- A way to use different versions of cordova on the same system/os.
- A way to specify cordova as a dependency in package.json for an App
project
- A way to sandbox cordova and checking into source control for an App
project
# [GruntJS](http://gruntjs.com/getting-started) is a project that already
takes this approach:
1. User installs `grunt-cli` globally instead of grunt
npm -g install grunt-cli`
2. User installs `grunt` locally
npm install grunt --save-dev
3. When user runs `grunt` it will run a short script `/usr/local/bin/grunt`
(about 40 lines)
It will resolve and use grunt from cwd (current working directory)
locally
# Proposal:
1. Have 2 npm packages
- cordova-cli
- cordova
2. create cordova-cli package and update docs
cordova-cli will be almost indentical to grunt-cli
https://github.com/gruntjs/grunt-cli/blob/master/bin/grunt
3. codova package is not longer get's install as `bin\cordova` and instead
run with
require(cordovapath).cli();
---
If you want to know more about grunt and why grunt swtiched from being
installed globally to now being install locally a podcast came out last
Friday where the author of GruntJS (Ben Alman) explains more details
http://javascriptjabber.com/074-jsj-grunt-js-with-ben-alman/
--
Carlos Santana
<cs...@gmail.com>
Re: cordova cli global vs. local install
Posted by Brian LeRoux <b...@brian.io>.
Last year I would've advocated we put our energy into something more
magical like grunt/grunt-cli as Michal describes. Nowadays I'm thinking we
focus on writing libs and let other ppl figure out glue w/ their Grunt. (Or
write the magical way but based on lower level smarter libs.)
On Mon, Sep 9, 2013 at 8:56 AM, Michal Mocny <mm...@chromium.org> wrote:
> I should add that one benefit of what I outlined above is that you only
> need to worry about installing cordova-cli once, and it could then
> manage/download the various versions of itself.
>
> The downside is that we would have to write those smarts, instead of just
> leveraging npm and forcing the user to take control.
>
> The grunt way is less magical, which has its benefits and drawbacks.
>
> -Michal
>
>
> On Mon, Sep 9, 2013 at 11:53 AM, Michal Mocny <mm...@chromium.org> wrote:
>
> > Generally, I like it. We've discussed a somewhat variant in the past,
> and
> > I'm not sure which is better:
> >
> > Instead of installing locally every time a la grunt, we discussed having
> a
> > single install base for the different cordova versions (i.e. inside
> > ~/.cordova), and then cordova-cli is a short script that forks to launch
> > the right version of cordova proper. The right version is (a) the most
> > recent version if you are creating a new app, or (b) the version that is
> > "tied" to a given workspace when used inside an existing app (and which
> you
> > must explicitly upgrade).
> >
> > -Michal
> >
> >
> > On Mon, Sep 9, 2013 at 11:48 AM, Carlos Santana <csantana23@gmail.com
> >wrote:
> >
> >> What does the community think of installing cordova only locally and not
> >> globally?
> >>
> >> # Installing Cordova locally will provide:
> >>
> >> - A way to use different versions of cordova on the same system/os.
> >> - A way to specify cordova as a dependency in package.json for an App
> >> project
> >> - A way to sandbox cordova and checking into source control for an App
> >> project
> >>
> >> # [GruntJS](http://gruntjs.com/getting-started) is a project that
> already
> >> takes this approach:
> >>
> >> 1. User installs `grunt-cli` globally instead of grunt
> >> npm -g install grunt-cli`
> >>
> >> 2. User installs `grunt` locally
> >> npm install grunt --save-dev
> >>
> >> 3. When user runs `grunt` it will run a short script
> >> `/usr/local/bin/grunt`
> >> (about 40 lines)
> >> It will resolve and use grunt from cwd (current working directory)
> >> locally
> >>
> >> # Proposal:
> >>
> >> 1. Have 2 npm packages
> >> - cordova-cli
> >> - cordova
> >>
> >> 2. create cordova-cli package and update docs
> >> cordova-cli will be almost indentical to grunt-cli
> >> https://github.com/gruntjs/grunt-cli/blob/master/bin/grunt
> >>
> >> 3. codova package is not longer get's install as `bin\cordova` and
> instead
> >> run with
> >> require(cordovapath).cli();
> >>
> >>
> >> ---
> >> If you want to know more about grunt and why grunt swtiched from being
> >> installed globally to now being install locally a podcast came out last
> >> Friday where the author of GruntJS (Ben Alman) explains more details
> >> http://javascriptjabber.com/074-jsj-grunt-js-with-ben-alman/
> >>
> >>
> >> --
> >> Carlos Santana
> >> <cs...@gmail.com>
> >>
> >
> >
>
Re: cordova cli global vs. local install
Posted by Michal Mocny <mm...@chromium.org>.
I should add that one benefit of what I outlined above is that you only
need to worry about installing cordova-cli once, and it could then
manage/download the various versions of itself.
The downside is that we would have to write those smarts, instead of just
leveraging npm and forcing the user to take control.
The grunt way is less magical, which has its benefits and drawbacks.
-Michal
On Mon, Sep 9, 2013 at 11:53 AM, Michal Mocny <mm...@chromium.org> wrote:
> Generally, I like it. We've discussed a somewhat variant in the past, and
> I'm not sure which is better:
>
> Instead of installing locally every time a la grunt, we discussed having a
> single install base for the different cordova versions (i.e. inside
> ~/.cordova), and then cordova-cli is a short script that forks to launch
> the right version of cordova proper. The right version is (a) the most
> recent version if you are creating a new app, or (b) the version that is
> "tied" to a given workspace when used inside an existing app (and which you
> must explicitly upgrade).
>
> -Michal
>
>
> On Mon, Sep 9, 2013 at 11:48 AM, Carlos Santana <cs...@gmail.com>wrote:
>
>> What does the community think of installing cordova only locally and not
>> globally?
>>
>> # Installing Cordova locally will provide:
>>
>> - A way to use different versions of cordova on the same system/os.
>> - A way to specify cordova as a dependency in package.json for an App
>> project
>> - A way to sandbox cordova and checking into source control for an App
>> project
>>
>> # [GruntJS](http://gruntjs.com/getting-started) is a project that already
>> takes this approach:
>>
>> 1. User installs `grunt-cli` globally instead of grunt
>> npm -g install grunt-cli`
>>
>> 2. User installs `grunt` locally
>> npm install grunt --save-dev
>>
>> 3. When user runs `grunt` it will run a short script
>> `/usr/local/bin/grunt`
>> (about 40 lines)
>> It will resolve and use grunt from cwd (current working directory)
>> locally
>>
>> # Proposal:
>>
>> 1. Have 2 npm packages
>> - cordova-cli
>> - cordova
>>
>> 2. create cordova-cli package and update docs
>> cordova-cli will be almost indentical to grunt-cli
>> https://github.com/gruntjs/grunt-cli/blob/master/bin/grunt
>>
>> 3. codova package is not longer get's install as `bin\cordova` and instead
>> run with
>> require(cordovapath).cli();
>>
>>
>> ---
>> If you want to know more about grunt and why grunt swtiched from being
>> installed globally to now being install locally a podcast came out last
>> Friday where the author of GruntJS (Ben Alman) explains more details
>> http://javascriptjabber.com/074-jsj-grunt-js-with-ben-alman/
>>
>>
>> --
>> Carlos Santana
>> <cs...@gmail.com>
>>
>
>
Re: cordova cli global vs. local install
Posted by Michal Mocny <mm...@chromium.org>.
Generally, I like it. We've discussed a somewhat variant in the past, and
I'm not sure which is better:
Instead of installing locally every time a la grunt, we discussed having a
single install base for the different cordova versions (i.e. inside
~/.cordova), and then cordova-cli is a short script that forks to launch
the right version of cordova proper. The right version is (a) the most
recent version if you are creating a new app, or (b) the version that is
"tied" to a given workspace when used inside an existing app (and which you
must explicitly upgrade).
-Michal
On Mon, Sep 9, 2013 at 11:48 AM, Carlos Santana <cs...@gmail.com>wrote:
> What does the community think of installing cordova only locally and not
> globally?
>
> # Installing Cordova locally will provide:
>
> - A way to use different versions of cordova on the same system/os.
> - A way to specify cordova as a dependency in package.json for an App
> project
> - A way to sandbox cordova and checking into source control for an App
> project
>
> # [GruntJS](http://gruntjs.com/getting-started) is a project that already
> takes this approach:
>
> 1. User installs `grunt-cli` globally instead of grunt
> npm -g install grunt-cli`
>
> 2. User installs `grunt` locally
> npm install grunt --save-dev
>
> 3. When user runs `grunt` it will run a short script `/usr/local/bin/grunt`
> (about 40 lines)
> It will resolve and use grunt from cwd (current working directory)
> locally
>
> # Proposal:
>
> 1. Have 2 npm packages
> - cordova-cli
> - cordova
>
> 2. create cordova-cli package and update docs
> cordova-cli will be almost indentical to grunt-cli
> https://github.com/gruntjs/grunt-cli/blob/master/bin/grunt
>
> 3. codova package is not longer get's install as `bin\cordova` and instead
> run with
> require(cordovapath).cli();
>
>
> ---
> If you want to know more about grunt and why grunt swtiched from being
> installed globally to now being install locally a podcast came out last
> Friday where the author of GruntJS (Ben Alman) explains more details
> http://javascriptjabber.com/074-jsj-grunt-js-with-ben-alman/
>
>
> --
> Carlos Santana
> <cs...@gmail.com>
>
Re: cordova cli global vs. local install
Posted by Andrew Grieve <ag...@chromium.org>.
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 <pu...@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 <mm...@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.
> >
> >
>
Re: cordova cli global vs. local install
Posted by Brian LeRoux <b...@brian.io>.
This is cool. I think slowly moving the `cordova` tool as it is today in
this direction is preferable to another tool. Its a way better workflow.
On Fri, Sep 20, 2013 at 6:22 PM, Michal Mocny <mm...@chromium.org> wrote:
> Some food for thought:
>
> * Cordova-cli uses a global ~/.cordova folder, which means each workspace
> is never fully isolated from all the others since they share global state.
> This means all versions of cordova-cli should be forwards and backwards
> compatible with the structure of ~/.cordova. **This is already true
> today** regardless of supporting local npm installs, because we run into
> this issue every time you upgrade your global version and have the old
> ~/.cordova around.
>
> * The wrapper I wrote defaults to creating a locally installed npm cordova
> for you, but that was just for testing. I think if we decide to add this
> to cordova-cli proper it should default to using a globally installed
> version (effectively what cordova-cli does right now). Cli would fork to
> local version only if you had a local install
> * Should still add a convenience helper "cordova create
> --version=@version" (something like that). This is useful for the reasons
> outlined earlier in this thread about the bootstrapping problem (i.e. you
> have to install cordova version in order to call its create method, but
> where do you install it if you haven't created workspace yet).
>
> * For the default "use globally installed cordova" option, do we add the
> smarts inside the wrapper to looking globally, or do we just leverage npm
> --link and always expect a local node_modules?
>
> * Do we want to add something like this right in to `cordova`, or leave it
> as a userland tool like it is now / publish to npm under a different
> package?
>
> -Michal
>
>
> On Fri, Sep 20, 2013 at 8:47 AM, Michal Mocny <mm...@chromium.org> wrote:
>
> > I decided to scratch this itch and have a super early version here:
> > https://github.com/mmocny/cordova-cli-wrapper
> >
> > README.md should describe more or less the usage.
> >
> > -Michal
> >
> >
> > On Tue, Sep 10, 2013 at 6:56 AM, Carlos Santana <csantana23@gmail.com
> >wrote:
> >
> >> 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 <pu...@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 <mm...@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
> >> <cs...@gmail.com>
> >>
> >
> >
>
Re: cordova cli global vs. local install
Posted by Michal Mocny <mm...@chromium.org>.
Some food for thought:
* Cordova-cli uses a global ~/.cordova folder, which means each workspace
is never fully isolated from all the others since they share global state.
This means all versions of cordova-cli should be forwards and backwards
compatible with the structure of ~/.cordova. **This is already true
today** regardless of supporting local npm installs, because we run into
this issue every time you upgrade your global version and have the old
~/.cordova around.
* The wrapper I wrote defaults to creating a locally installed npm cordova
for you, but that was just for testing. I think if we decide to add this
to cordova-cli proper it should default to using a globally installed
version (effectively what cordova-cli does right now). Cli would fork to
local version only if you had a local install
* Should still add a convenience helper "cordova create
--version=@version" (something like that). This is useful for the reasons
outlined earlier in this thread about the bootstrapping problem (i.e. you
have to install cordova version in order to call its create method, but
where do you install it if you haven't created workspace yet).
* For the default "use globally installed cordova" option, do we add the
smarts inside the wrapper to looking globally, or do we just leverage npm
--link and always expect a local node_modules?
* Do we want to add something like this right in to `cordova`, or leave it
as a userland tool like it is now / publish to npm under a different
package?
-Michal
On Fri, Sep 20, 2013 at 8:47 AM, Michal Mocny <mm...@chromium.org> wrote:
> I decided to scratch this itch and have a super early version here:
> https://github.com/mmocny/cordova-cli-wrapper
>
> README.md should describe more or less the usage.
>
> -Michal
>
>
> On Tue, Sep 10, 2013 at 6:56 AM, Carlos Santana <cs...@gmail.com>wrote:
>
>> 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 <pu...@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 <mm...@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
>> <cs...@gmail.com>
>>
>
>
Re: cordova cli global vs. local install
Posted by Michal Mocny <mm...@chromium.org>.
I decided to scratch this itch and have a super early version here:
https://github.com/mmocny/cordova-cli-wrapper
README.md should describe more or less the usage.
-Michal
On Tue, Sep 10, 2013 at 6:56 AM, Carlos Santana <cs...@gmail.com>wrote:
> 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 <pu...@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 <mm...@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
> <cs...@gmail.com>
>
Re: cordova cli global vs. local install
Posted by Carlos Santana <cs...@gmail.com>.
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 <pu...@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 <mm...@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
<cs...@gmail.com>
Re: cordova cli global vs. local install
Posted by Jesse <pu...@gmail.com>.
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 <mm...@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.
>
>
Re: cordova cli global vs. local install
Posted by Tommy-Carlos Williams <to...@devgeeks.org>.
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 <mm...@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.
Re: cordova cli global vs. local install
Posted by Michal Mocny <mm...@chromium.org>.
If we have the global cordova-cli doing the create step, we are basically
describing the earlier stated "magical" approach, and pointing out that we
could leverage npm for some of the smarts (rightly so, perhaps).
If we do this, I think it means we would have a node_modules/ alongside
platforms/ and plugins/ etc (are we okay with that?). I would also suggest
running npm install automatically, so the user sees no change to existing
workflow, outside of how they do upgrades (must upgrade cordova lib locally
per each workspace).
Also, we should acknowledge that this trades one problem (currently: a
single global cordova-cli means upgrades affect every workspace), for
another problem (proposed: local cordova-libs mean you have to explicitly
upgrade each workspace, and understand that upgrading your global
cordova-cli does nothing). Could we warn about stale local versions, or
echo the cordova lib version used (during prepare/serve/etc?) so as to give
visual feedback?
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.
-Michal
On Mon, Sep 9, 2013 at 7:07 PM, Tommy-Carlos Williams <to...@devgeeks.org>wrote:
> Also to be clear, I was advocating a cordova/cordova-cli approach similar
> to grunt/grunt-cli, not actually enforcing some kind of grunt workflow on
> people.
>
> However, I agree with Michal that we need to think carefully about this.
>
> This is quite a lot of cli to create an initial app:
>
> mkdir helloworld && cd helloworld && npm init && npm install --save-dev
> cordova && cordova create . org.devgeeks.helloworld helloworld
>
>
> So some additional questions for thinking about… (I don't know any
> answers, just throwing out suggestions and ideas).
>
> Could the cordova-cli still do the create stage with the default template
> also including a package.json with a dev-dependency of cordova? Create
> does not need to deal with the platforms.. that is done when adding a
> platform (which could therefore be handled by the local cordova
> node_module).
>
> cordova create helloworld org.devgeeks.helloworld helloworld && cd
> helloworld && npm install
>
> ?
>
> - tommy
>
> On 10/09/2013, at 11:49 AM, Michal Mocny <mm...@chromium.org> wrote:
>
> > What if the first step is to add to cordova-cli a startup check to see if
> > you have a locally installed cordova which is not the current executable?
> >
> > I do agree with your Carlos that what you propose is good, but I'm
> > concerned about some details. For example, how do I bootstrap the
> process?
> > With grunt, you are usually adding to an existing app with an existing
> > directory structure. With cordova, its usually the one to create the
> > workspace. Would I need to create an empty directory to hold a
> > node_modules so that I first install cordova-cli, and then run cordova
> > create to get another subdirectory to hold my workspace?
> >
> >> mkdir HelloWorld && cd HelloWorld && npm install cordova && cordova
> > create HelloWorld
> >
> > ...for each project? Note that here the `cordova` used in npm install
> > refers to a lib, and `cordova` used from command line refers to
> > cordova-cli's small wrapper script, as grunt does it, which is not super
> > clear to users.
> >
> > I'm overall very interesting in solving the problem you describe, but I'd
> > like to think through the full use case.
> >
> > -Michal
> >
> >
> > On Mon, Sep 9, 2013 at 5:27 PM, Carlos Santana <cs...@gmail.com>
> wrote:
> >
> >> Just to be clear I'm not proposing that we use grunt-cli/grunt to manage
> >> the cordova versions.
> >>
> >> What I'm proposing is to have less magic than what we have today in
> >> cordova, and be more practical (at least from my point of view)
> >>
> >> I think I'm bringing this forward because I'm having difficulty
> integrating
> >> "glue" with cordova.
> >>
> >> cordova is an npm package (which I consider a lib/module/building-block)
> >> but we advertise as a global tool.
> >>
> >> I'm trying to instrument cordova just as any other front end tool to do
> web
> >> app development, I'm running cordova not by hand from command prompt.
> >>
> >> Today if cordova is install globally at version 3.0.6 and locally at
> 3.0.8
> >> Then it depends how the tools is executed from /usr/local/bin/cordova or
> >> ./node_modules/.bin/cordova
> >>
> >> When a user open jira item with a cordova problem and we ask what
> version
> >> of cordova they are using, don't be surprise if they think they running
> one
> >> version, but actually a different one if they are using node and not the
> >> command prompt.
> >>
> >> I don't have strong opinions either way, I just wanted to know what the
> >> community thought about this topic
> >>
> >> I'm happy running `$PWD/node_modules/.bin/cordova` for now and I know
> I'm
> >> going to get predictable results :-)
> >>
> >> --Carlos
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Mon, Sep 9, 2013 at 6:12 PM, Tommy-Carlos Williams <
> tommy@devgeeks.org
> >>> wrote:
> >>
> >>> +1 for the more straight forward easy win of the grunt/grunt-cli model.
> >>>
> >>> I see the benefits of Michal's suggestion, but I agree that our efforts
> >>> are best spent elsewhere.
> >>>
> >>> Let users take control of versions as with other npm
> >>> modules/frameworks/libs. Just set the cordova version in package.json.
> >> With
> >>> core no longer having all the apis in it, it's no longer a massive dep,
> >> so
> >>> having it downloaded for each project is less of an issue, surely?
> >>>
> >>> - tommy
> >>>
> >>>
> >>>
> >>> On 10/09/2013, at 1:48 AM, Carlos Santana <cs...@gmail.com>
> wrote:
> >>>
> >>>> What does the community think of installing cordova only locally and
> >> not
> >>>> globally?
> >>>>
> >>>> # Installing Cordova locally will provide:
> >>>>
> >>>> - A way to use different versions of cordova on the same system/os.
> >>>> - A way to specify cordova as a dependency in package.json for an App
> >>>> project
> >>>> - A way to sandbox cordova and checking into source control for an
> App
> >>>> project
> >>>>
> >>>> # [GruntJS](http://gruntjs.com/getting-started) is a project that
> >>> already
> >>>> takes this approach:
> >>>>
> >>>> 1. User installs `grunt-cli` globally instead of grunt
> >>>> npm -g install grunt-cli`
> >>>>
> >>>> 2. User installs `grunt` locally
> >>>> npm install grunt --save-dev
> >>>>
> >>>> 3. When user runs `grunt` it will run a short script
> >>> `/usr/local/bin/grunt`
> >>>> (about 40 lines)
> >>>> It will resolve and use grunt from cwd (current working directory)
> >>>> locally
> >>>>
> >>>> # Proposal:
> >>>>
> >>>> 1. Have 2 npm packages
> >>>> - cordova-cli
> >>>> - cordova
> >>>>
> >>>> 2. create cordova-cli package and update docs
> >>>> cordova-cli will be almost indentical to grunt-cli
> >>>> https://github.com/gruntjs/grunt-cli/blob/master/bin/grunt
> >>>>
> >>>> 3. codova package is not longer get's install as `bin\cordova` and
> >>> instead
> >>>> run with
> >>>> require(cordovapath).cli();
> >>>>
> >>>>
> >>>> ---
> >>>> If you want to know more about grunt and why grunt swtiched from being
> >>>> installed globally to now being install locally a podcast came out
> last
> >>>> Friday where the author of GruntJS (Ben Alman) explains more details
> >>>> http://javascriptjabber.com/074-jsj-grunt-js-with-ben-alman/
> >>>>
> >>>>
> >>>> --
> >>>> Carlos Santana
> >>>> <cs...@gmail.com>
> >>>
> >>>
> >>
> >>
> >> --
> >> Carlos Santana
> >> <cs...@gmail.com>
> >>
>
>
Re: cordova cli global vs. local install
Posted by Tommy-Carlos Williams <to...@devgeeks.org>.
Also to be clear, I was advocating a cordova/cordova-cli approach similar to grunt/grunt-cli, not actually enforcing some kind of grunt workflow on people.
However, I agree with Michal that we need to think carefully about this.
This is quite a lot of cli to create an initial app:
mkdir helloworld && cd helloworld && npm init && npm install --save-dev cordova && cordova create . org.devgeeks.helloworld helloworld
So some additional questions for thinking about… (I don't know any answers, just throwing out suggestions and ideas).
Could the cordova-cli still do the create stage with the default template also including a package.json with a dev-dependency of cordova? Create does not need to deal with the platforms.. that is done when adding a platform (which could therefore be handled by the local cordova node_module).
cordova create helloworld org.devgeeks.helloworld helloworld && cd helloworld && npm install
?
- tommy
On 10/09/2013, at 11:49 AM, Michal Mocny <mm...@chromium.org> wrote:
> What if the first step is to add to cordova-cli a startup check to see if
> you have a locally installed cordova which is not the current executable?
>
> I do agree with your Carlos that what you propose is good, but I'm
> concerned about some details. For example, how do I bootstrap the process?
> With grunt, you are usually adding to an existing app with an existing
> directory structure. With cordova, its usually the one to create the
> workspace. Would I need to create an empty directory to hold a
> node_modules so that I first install cordova-cli, and then run cordova
> create to get another subdirectory to hold my workspace?
>
>> mkdir HelloWorld && cd HelloWorld && npm install cordova && cordova
> create HelloWorld
>
> ...for each project? Note that here the `cordova` used in npm install
> refers to a lib, and `cordova` used from command line refers to
> cordova-cli's small wrapper script, as grunt does it, which is not super
> clear to users.
>
> I'm overall very interesting in solving the problem you describe, but I'd
> like to think through the full use case.
>
> -Michal
>
>
> On Mon, Sep 9, 2013 at 5:27 PM, Carlos Santana <cs...@gmail.com> wrote:
>
>> Just to be clear I'm not proposing that we use grunt-cli/grunt to manage
>> the cordova versions.
>>
>> What I'm proposing is to have less magic than what we have today in
>> cordova, and be more practical (at least from my point of view)
>>
>> I think I'm bringing this forward because I'm having difficulty integrating
>> "glue" with cordova.
>>
>> cordova is an npm package (which I consider a lib/module/building-block)
>> but we advertise as a global tool.
>>
>> I'm trying to instrument cordova just as any other front end tool to do web
>> app development, I'm running cordova not by hand from command prompt.
>>
>> Today if cordova is install globally at version 3.0.6 and locally at 3.0.8
>> Then it depends how the tools is executed from /usr/local/bin/cordova or
>> ./node_modules/.bin/cordova
>>
>> When a user open jira item with a cordova problem and we ask what version
>> of cordova they are using, don't be surprise if they think they running one
>> version, but actually a different one if they are using node and not the
>> command prompt.
>>
>> I don't have strong opinions either way, I just wanted to know what the
>> community thought about this topic
>>
>> I'm happy running `$PWD/node_modules/.bin/cordova` for now and I know I'm
>> going to get predictable results :-)
>>
>> --Carlos
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Sep 9, 2013 at 6:12 PM, Tommy-Carlos Williams <tommy@devgeeks.org
>>> wrote:
>>
>>> +1 for the more straight forward easy win of the grunt/grunt-cli model.
>>>
>>> I see the benefits of Michal's suggestion, but I agree that our efforts
>>> are best spent elsewhere.
>>>
>>> Let users take control of versions as with other npm
>>> modules/frameworks/libs. Just set the cordova version in package.json.
>> With
>>> core no longer having all the apis in it, it's no longer a massive dep,
>> so
>>> having it downloaded for each project is less of an issue, surely?
>>>
>>> - tommy
>>>
>>>
>>>
>>> On 10/09/2013, at 1:48 AM, Carlos Santana <cs...@gmail.com> wrote:
>>>
>>>> What does the community think of installing cordova only locally and
>> not
>>>> globally?
>>>>
>>>> # Installing Cordova locally will provide:
>>>>
>>>> - A way to use different versions of cordova on the same system/os.
>>>> - A way to specify cordova as a dependency in package.json for an App
>>>> project
>>>> - A way to sandbox cordova and checking into source control for an App
>>>> project
>>>>
>>>> # [GruntJS](http://gruntjs.com/getting-started) is a project that
>>> already
>>>> takes this approach:
>>>>
>>>> 1. User installs `grunt-cli` globally instead of grunt
>>>> npm -g install grunt-cli`
>>>>
>>>> 2. User installs `grunt` locally
>>>> npm install grunt --save-dev
>>>>
>>>> 3. When user runs `grunt` it will run a short script
>>> `/usr/local/bin/grunt`
>>>> (about 40 lines)
>>>> It will resolve and use grunt from cwd (current working directory)
>>>> locally
>>>>
>>>> # Proposal:
>>>>
>>>> 1. Have 2 npm packages
>>>> - cordova-cli
>>>> - cordova
>>>>
>>>> 2. create cordova-cli package and update docs
>>>> cordova-cli will be almost indentical to grunt-cli
>>>> https://github.com/gruntjs/grunt-cli/blob/master/bin/grunt
>>>>
>>>> 3. codova package is not longer get's install as `bin\cordova` and
>>> instead
>>>> run with
>>>> require(cordovapath).cli();
>>>>
>>>>
>>>> ---
>>>> If you want to know more about grunt and why grunt swtiched from being
>>>> installed globally to now being install locally a podcast came out last
>>>> Friday where the author of GruntJS (Ben Alman) explains more details
>>>> http://javascriptjabber.com/074-jsj-grunt-js-with-ben-alman/
>>>>
>>>>
>>>> --
>>>> Carlos Santana
>>>> <cs...@gmail.com>
>>>
>>>
>>
>>
>> --
>> Carlos Santana
>> <cs...@gmail.com>
>>
Re: cordova cli global vs. local install
Posted by Michal Mocny <mm...@chromium.org>.
What if the first step is to add to cordova-cli a startup check to see if
you have a locally installed cordova which is not the current executable?
I do agree with your Carlos that what you propose is good, but I'm
concerned about some details. For example, how do I bootstrap the process?
With grunt, you are usually adding to an existing app with an existing
directory structure. With cordova, its usually the one to create the
workspace. Would I need to create an empty directory to hold a
node_modules so that I first install cordova-cli, and then run cordova
create to get another subdirectory to hold my workspace?
> mkdir HelloWorld && cd HelloWorld && npm install cordova && cordova
create HelloWorld
...for each project? Note that here the `cordova` used in npm install
refers to a lib, and `cordova` used from command line refers to
cordova-cli's small wrapper script, as grunt does it, which is not super
clear to users.
I'm overall very interesting in solving the problem you describe, but I'd
like to think through the full use case.
-Michal
On Mon, Sep 9, 2013 at 5:27 PM, Carlos Santana <cs...@gmail.com> wrote:
> Just to be clear I'm not proposing that we use grunt-cli/grunt to manage
> the cordova versions.
>
> What I'm proposing is to have less magic than what we have today in
> cordova, and be more practical (at least from my point of view)
>
> I think I'm bringing this forward because I'm having difficulty integrating
> "glue" with cordova.
>
> cordova is an npm package (which I consider a lib/module/building-block)
> but we advertise as a global tool.
>
> I'm trying to instrument cordova just as any other front end tool to do web
> app development, I'm running cordova not by hand from command prompt.
>
> Today if cordova is install globally at version 3.0.6 and locally at 3.0.8
> Then it depends how the tools is executed from /usr/local/bin/cordova or
> ./node_modules/.bin/cordova
>
> When a user open jira item with a cordova problem and we ask what version
> of cordova they are using, don't be surprise if they think they running one
> version, but actually a different one if they are using node and not the
> command prompt.
>
> I don't have strong opinions either way, I just wanted to know what the
> community thought about this topic
>
> I'm happy running `$PWD/node_modules/.bin/cordova` for now and I know I'm
> going to get predictable results :-)
>
> --Carlos
>
>
>
>
>
>
>
>
>
> On Mon, Sep 9, 2013 at 6:12 PM, Tommy-Carlos Williams <tommy@devgeeks.org
> >wrote:
>
> > +1 for the more straight forward easy win of the grunt/grunt-cli model.
> >
> > I see the benefits of Michal's suggestion, but I agree that our efforts
> > are best spent elsewhere.
> >
> > Let users take control of versions as with other npm
> > modules/frameworks/libs. Just set the cordova version in package.json.
> With
> > core no longer having all the apis in it, it's no longer a massive dep,
> so
> > having it downloaded for each project is less of an issue, surely?
> >
> > - tommy
> >
> >
> >
> > On 10/09/2013, at 1:48 AM, Carlos Santana <cs...@gmail.com> wrote:
> >
> > > What does the community think of installing cordova only locally and
> not
> > > globally?
> > >
> > > # Installing Cordova locally will provide:
> > >
> > > - A way to use different versions of cordova on the same system/os.
> > > - A way to specify cordova as a dependency in package.json for an App
> > > project
> > > - A way to sandbox cordova and checking into source control for an App
> > > project
> > >
> > > # [GruntJS](http://gruntjs.com/getting-started) is a project that
> > already
> > > takes this approach:
> > >
> > > 1. User installs `grunt-cli` globally instead of grunt
> > > npm -g install grunt-cli`
> > >
> > > 2. User installs `grunt` locally
> > > npm install grunt --save-dev
> > >
> > > 3. When user runs `grunt` it will run a short script
> > `/usr/local/bin/grunt`
> > > (about 40 lines)
> > > It will resolve and use grunt from cwd (current working directory)
> > > locally
> > >
> > > # Proposal:
> > >
> > > 1. Have 2 npm packages
> > > - cordova-cli
> > > - cordova
> > >
> > > 2. create cordova-cli package and update docs
> > > cordova-cli will be almost indentical to grunt-cli
> > > https://github.com/gruntjs/grunt-cli/blob/master/bin/grunt
> > >
> > > 3. codova package is not longer get's install as `bin\cordova` and
> > instead
> > > run with
> > > require(cordovapath).cli();
> > >
> > >
> > > ---
> > > If you want to know more about grunt and why grunt swtiched from being
> > > installed globally to now being install locally a podcast came out last
> > > Friday where the author of GruntJS (Ben Alman) explains more details
> > > http://javascriptjabber.com/074-jsj-grunt-js-with-ben-alman/
> > >
> > >
> > > --
> > > Carlos Santana
> > > <cs...@gmail.com>
> >
> >
>
>
> --
> Carlos Santana
> <cs...@gmail.com>
>
Re: cordova cli global vs. local install
Posted by Carlos Santana <cs...@gmail.com>.
Just to be clear I'm not proposing that we use grunt-cli/grunt to manage
the cordova versions.
What I'm proposing is to have less magic than what we have today in
cordova, and be more practical (at least from my point of view)
I think I'm bringing this forward because I'm having difficulty integrating
"glue" with cordova.
cordova is an npm package (which I consider a lib/module/building-block)
but we advertise as a global tool.
I'm trying to instrument cordova just as any other front end tool to do web
app development, I'm running cordova not by hand from command prompt.
Today if cordova is install globally at version 3.0.6 and locally at 3.0.8
Then it depends how the tools is executed from /usr/local/bin/cordova or
./node_modules/.bin/cordova
When a user open jira item with a cordova problem and we ask what version
of cordova they are using, don't be surprise if they think they running one
version, but actually a different one if they are using node and not the
command prompt.
I don't have strong opinions either way, I just wanted to know what the
community thought about this topic
I'm happy running `$PWD/node_modules/.bin/cordova` for now and I know I'm
going to get predictable results :-)
--Carlos
On Mon, Sep 9, 2013 at 6:12 PM, Tommy-Carlos Williams <to...@devgeeks.org>wrote:
> +1 for the more straight forward easy win of the grunt/grunt-cli model.
>
> I see the benefits of Michal's suggestion, but I agree that our efforts
> are best spent elsewhere.
>
> Let users take control of versions as with other npm
> modules/frameworks/libs. Just set the cordova version in package.json. With
> core no longer having all the apis in it, it's no longer a massive dep, so
> having it downloaded for each project is less of an issue, surely?
>
> - tommy
>
>
>
> On 10/09/2013, at 1:48 AM, Carlos Santana <cs...@gmail.com> wrote:
>
> > What does the community think of installing cordova only locally and not
> > globally?
> >
> > # Installing Cordova locally will provide:
> >
> > - A way to use different versions of cordova on the same system/os.
> > - A way to specify cordova as a dependency in package.json for an App
> > project
> > - A way to sandbox cordova and checking into source control for an App
> > project
> >
> > # [GruntJS](http://gruntjs.com/getting-started) is a project that
> already
> > takes this approach:
> >
> > 1. User installs `grunt-cli` globally instead of grunt
> > npm -g install grunt-cli`
> >
> > 2. User installs `grunt` locally
> > npm install grunt --save-dev
> >
> > 3. When user runs `grunt` it will run a short script
> `/usr/local/bin/grunt`
> > (about 40 lines)
> > It will resolve and use grunt from cwd (current working directory)
> > locally
> >
> > # Proposal:
> >
> > 1. Have 2 npm packages
> > - cordova-cli
> > - cordova
> >
> > 2. create cordova-cli package and update docs
> > cordova-cli will be almost indentical to grunt-cli
> > https://github.com/gruntjs/grunt-cli/blob/master/bin/grunt
> >
> > 3. codova package is not longer get's install as `bin\cordova` and
> instead
> > run with
> > require(cordovapath).cli();
> >
> >
> > ---
> > If you want to know more about grunt and why grunt swtiched from being
> > installed globally to now being install locally a podcast came out last
> > Friday where the author of GruntJS (Ben Alman) explains more details
> > http://javascriptjabber.com/074-jsj-grunt-js-with-ben-alman/
> >
> >
> > --
> > Carlos Santana
> > <cs...@gmail.com>
>
>
--
Carlos Santana
<cs...@gmail.com>
Re: cordova cli global vs. local install
Posted by Tommy-Carlos Williams <to...@devgeeks.org>.
+1 for the more straight forward easy win of the grunt/grunt-cli model.
I see the benefits of Michal's suggestion, but I agree that our efforts are best spent elsewhere.
Let users take control of versions as with other npm modules/frameworks/libs. Just set the cordova version in package.json. With core no longer having all the apis in it, it's no longer a massive dep, so having it downloaded for each project is less of an issue, surely?
- tommy
On 10/09/2013, at 1:48 AM, Carlos Santana <cs...@gmail.com> wrote:
> What does the community think of installing cordova only locally and not
> globally?
>
> # Installing Cordova locally will provide:
>
> - A way to use different versions of cordova on the same system/os.
> - A way to specify cordova as a dependency in package.json for an App
> project
> - A way to sandbox cordova and checking into source control for an App
> project
>
> # [GruntJS](http://gruntjs.com/getting-started) is a project that already
> takes this approach:
>
> 1. User installs `grunt-cli` globally instead of grunt
> npm -g install grunt-cli`
>
> 2. User installs `grunt` locally
> npm install grunt --save-dev
>
> 3. When user runs `grunt` it will run a short script `/usr/local/bin/grunt`
> (about 40 lines)
> It will resolve and use grunt from cwd (current working directory)
> locally
>
> # Proposal:
>
> 1. Have 2 npm packages
> - cordova-cli
> - cordova
>
> 2. create cordova-cli package and update docs
> cordova-cli will be almost indentical to grunt-cli
> https://github.com/gruntjs/grunt-cli/blob/master/bin/grunt
>
> 3. codova package is not longer get's install as `bin\cordova` and instead
> run with
> require(cordovapath).cli();
>
>
> ---
> If you want to know more about grunt and why grunt swtiched from being
> installed globally to now being install locally a podcast came out last
> Friday where the author of GruntJS (Ben Alman) explains more details
> http://javascriptjabber.com/074-jsj-grunt-js-with-ben-alman/
>
>
> --
> Carlos Santana
> <cs...@gmail.com>