cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: cordova cli global vs. local install
Date Tue, 10 Sep 2013 03:42:26 GMT
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 <tommy@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 <mmocny@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 <csantana23@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 <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
> >>>> <csantana23@gmail.com>
> >>>
> >>>
> >>
> >>
> >> --
> >> Carlos Santana
> >> <csantana23@gmail.com>
> >>
>
>

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