cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <>
Subject Re: Issues with CLI
Date Wed, 06 Mar 2013 22:52:14 GMT
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

On 3/6/13 9:29 AM, "Patrick Mueller" <> wrote:

>On Tue, Mar 5, 2013 at 2:39 PM, Becky Gibson <>
>> 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
>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
>    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
>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`
>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
>Check out what grunt recently did with their package:
>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
>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
>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,
>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
> 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

View raw message