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" <pmue...@gmail.com> wrote: >On Tue, Mar 5, 2013 at 2:39 PM, Becky Gibson <gibson.be...@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
