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 fil@adobe.com designates
 64.18.1.189 as permitted sender)
From: Filip Maj <fil@adobe.com>
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Date: Wed, 6 Mar 2013 14:52:14 -0800
Subject: Re: Issues with CLI
Thread-Topic: Issues with CLI
Thread-Index: Ac4avT8V4kXsKIFYRn2M6tqL3uIUQg==
Message-ID: <CD5D0849.1948C%fil@adobe.com>
In-Reply-To: 
 <CACAoQH3CxFFhAwxouiTPn1E7ykO3m_besHrgiPDcN2mvhMQxqw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.3.1.130117
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Quick update.

1. Closed the issue re: adding version number into js script ref
2. Pushed 2.5.3 to npm. I've added the temp/ and spec/fixtures dirs to the
.npmignore file. This reduces the tar size of the module from 60MB to
18MB. I was testing using the `npm pack` command, which just generates the
final .tar that gets uploaded to npm. Hopefully this makes the pain a bit
easier.

On 3/6/13 9:29 AM, "Patrick Mueller" <pmuellr@gmail.com> wrote:

>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.
>
>--=20
>Patrick Mueller
>http://muellerware.org