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 21:25:32 GMT
Thanks Pat, I'll take a look at what's packaged and see if we can trim
some of this fat. The plist module, if it is 15MB, is ridiculousÅ  I'll add
some stuff to the .npmignore file so the obvious stuff like temp,
fixtures, etc don't get packed up when doing an npm publish.

The spec/fixtures directory gets created only once you have cloned down
the repo [1], so to be clear no one DOWNLOADS spec/fixtures. Perhaps to
alleviate this, I split out some of the test-specific bootstrapping out of
the post-install bootstrap.js and instead put it in its own file that will
only be run/consumed when running tool tests.


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