Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (athena.apache.org: domain of pmuellr@gmail.com designates
 209.85.128.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CADjNb+n9+yb3u+PjF-f2hCcQQb0zg6fKmbwSEQ=9h0PLDP5=qA@mail.gmail.com>
References: 
 <CADjNb+n9+yb3u+PjF-f2hCcQQb0zg6fKmbwSEQ=9h0PLDP5=qA@mail.gmail.com>
Date: Wed, 6 Mar 2013 12:29:47 -0500
Message-ID: 
 <CACAoQH3CxFFhAwxouiTPn1E7ykO3m_besHrgiPDcN2mvhMQxqw@mail.gmail.com>
Subject: Re: Issues with CLI
From: Patrick Mueller <pmuellr@gmail.com>
To: dev@cordova.apache.org
Content-Type: multipart/alternative; boundary=20cf3079bb28cea30504d744efc2

--20cf3079bb28cea30504d744efc2
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Mar 5, 2013 at 2:39 PM, Becky Gibson <gibson.becky@gmail.com> wrote:

> I played around a bit with cordova-cli and have a few comments and
> questions.


Been a long time since I've looked at this, so I just did, and have a few
comments.

Nice work so far!

First, to get going quickly, I did this:

    cd ~/tmp
    mkdir cli
    cd cli
    touch package.json
    npm install cordova

18 minutes later (!!!) the beast was done installing.  Curious about the
size, I did a `du -h -d3` or some such, and here are some interesting
thangs:

    5.1M ./node_modules/cordova/lib/cordova-android
    2.6M ./node_modules/cordova/lib/cordova-blackberry
    8.9M ./node_modules/cordova/lib/cordova-ios
    ----
     17M ./node_modules/cordova/lib

     15M ./node_modules/cordova/node_modules/plist
    1.8M ./node_modules/cordova/node_modules/plugman
    1.8M ./node_modules/cordova/node_modules/prompt
    ----
     23M ./node_modules/cordova/node_modules

     28M ./node_modules/cordova/spec/fixtures

    4.0K ./node_modules/cordova/temp/.cordova
    6.6M ./node_modules/cordova/temp/www
    ----
    6.6M ./node_modules/cordova/temp

    ----
     81M ./node_modules/cordova

Some simple stuff first - add the `temp` directory to your .npmignore so it
doesn't get added to the package when publishing.  And I wonder why plist,
plugman, and prompt are so big?  (didn't investigate).

So a big chunk of this change comes from our test cases `spec/fixtures` and
runtime libraries `lib/cordova-*`.

Basically we're shipping the tool(s), the runtimes, and the tests all in
one big package.  Seems like we shouldn't be doing this, at least long term.

Check out what grunt recently did with their package:

    http://gruntjs.com/blog/2013-02-18-grunt-0.4.0-released

It now ships a tool that you install globally, and then when you want to
use grunt in one of your packages, you add the grunt runtime and plugins to
your package.  Of course, this means your tooling needs to be able to
handle any version of the runtime and plugins.  Prolly can't do that now -
for us - but a nice long-term.

I think the work-flow I'd like to see, in terms of how wads of runtimes,
tests, plugins are handled is something like this:

- install the command-line tool globally, once

- optionally cache runtimes, tests, plugins via the globally command

- `cordova platform add foo` would then use the cached runtime, if
available, or download it if not

- same for plugins and tests and whatever else

- I'd want to be able to set the cordova version in my project; another cli
command `cordova version xyz` that writes to a file in the project.
 Thereafter, you never need to specify a cordova version for your project.

- the cached runtimes, plugins, versions would all be versioned, so I can
have multiple versions of cordova installed simultaneously on my box, and
so have different projects using different versions, but the same tools, at
the same time.

Until we get to a point where the shapes of runtimes, plugins, etc isn't
changing, we can't really have a single global command that works across
versions.  Kind of.  You could imagine the single global command - for now
- also downloads the "real" tooling for the specific version, based on
whatever version you set.  Either store that in the project as well (it's
just JS code), or in the cache.  We can arrange to have the hefty pre-reqs
like `plist` downloaded with the global tool shim, and then pass it along
to the version-specific tool meat.

I think it may well make sense to make the runtimes, plugins, etc as npm
packages, but I'm not sure it makes sense to actually put them in npmjs.org.
 What I'm thinking is that our cli can programmatically use npm, and then
allow it to work off multiple, user-specified repositories.  The existing
npm cli doesn't make it easy to deal with multiple, or even non-default
repos, but presumably this is easier from the npm module itself.  We
wouldn't even have to run an actual npm server, we could arrange for our
code to download lists of modules it gets from somewhere, where the repo
for the package eventually points to a plain ol' tar.gz of the package, or
a git repo, or whatever.

-- 
Patrick Mueller
http://muellerware.org

--20cf3079bb28cea30504d744efc2--