WRT plugins not being tied to a version of the platforms… We at SpiderOak have a project that is still stuck at 3.0.0 for precisely that reason.
As for the CLI not being tied to a platform version, that’s also not true. Don’t know if you have tried it, but using a current version of the CLI with a project created and “platformed” with a previous version is also a recipe for disaster. On 5 June 2014 at 8:48:48, Brian LeRoux (b...@brian.io) wrote: Plugins have to target specific versions. [1] Core plugins, our org.apache plugins, are cross platform. [2] This is not conceptual but the current reality and a correct software practice. [1] https://github.com/apache/cordova-plugin-inappbrowser/blob/master/plugin.xml#L33 [2] https://github.com/apache/cordova-plugin-inappbrowser/tree/master/src On Wed, Jun 4, 2014 at 5:32 PM, Terence M. Bandoian <tere...@tmbsw.com> wrote: > Why is having different versions of platforms a recipe for disaster? > > -Terence > > > On 6/4/2014 4:29 PM, Brian LeRoux wrote: > >> As discussed: having different versions of platforms and plugins is a >> recipe for disaster. The design choice of version locking is deliberate to >> avoid that. I'm going to ignore the ramble about grunt, etc. I'm not >> advocating for that nor am I interested in javascript build library >> fashion. Those things are not problems we seek to solve here. >> >> Also: this is not talk. Its building consensus to *continue* the work >> being >> done into a direction that everyone feels good about. The alternative is >> patchbombing and a massive delete of google employee commits which is >> probably not productive. >> >> >> >> On Wed, Jun 4, 2014 at 2:16 PM, Andrew Grieve <agri...@chromium.org> >> wrote: >> >> Brian's and Carlos' examples have a very important difference: >>> >>> Brian's: platforms are dependencies of CLI >>> Carlos': platforms are siblings of CLI in top-level package.json >>> >>> With Carlos', the user can easily control versions of the platforms, >>> which >>> is great. You could just as easily put plugins in there now that npm >>> supports multiple registries as well. >>> >>> I don't think you'd need CLI at all with this setup. Just use plugman & >>> grunt & recreate your project on every build. I think it's a nice >>> workflow, >>> but I'm afraid that dramatically changing out documented workflow again >>> so >>> soon would be an unwelcome change. I also think it'd be a good amount of >>> work to make our tools smart enough to work alongside npm in a way that >>> isn't confusing (e.g. if we're recreating every time, we'll need to speed >>> it up a lot. If not, then you need to tell it when dependencies change). >>> >>> My main goal for now is to get to where we can release platforms >>> independently, but I'm curious if this is all talk or is anyone intending >>> to do some real exploration in this area? >>> >>> >>> >>> >>> >>> >>> >>> On Wed, Jun 4, 2014 at 4:55 PM, Brian LeRoux <b...@brian.io> wrote: >>> >>> Here is an example using our current situation. Cordova is versioned [1] >>>> and the CLI calls are abstracted as npm scripts [2]. If we change to the >>>> proposed 'versioning platforms using npm' we don't have to download >>>> platforms, cache them or perform any custom dependency logic. >>>> >>>> We will then be well on the path to making the CLI *really* dumb and it >>>> will only pass calls down to the lib installed in node_modules. >>>> >>>> HTH >>>> >>>> [1] >>>> >>>> >>>> https://github.com/brianleroux/cordova-example- >>> using-npm/blob/master/package.json#L13 >>> >>>> [2] >>>> >>>> >>>> https://github.com/brianleroux/cordova-example- >>> using-npm/blob/master/package.json#L8 >>> >>>> >>>> On Wed, Jun 4, 2014 at 1:38 PM, Carlos Santana <csantan...@gmail.com> >>>> wrote: >>>> >>>> Michal >>>>> The grunt plugin and yeoman generator I implemented a long ago. So >>>>> >>>> it's >>> >>>> implemented on top of what cordova provides. >>>>> >>>>> I'm confuse, this is the point I was trying to get that there is "user >>>>> space" and "cordova platform space", Doing a plugin for yeoman, gulp , >>>>> grunt, or the next thing is user space. >>>>> >>>>> cordova as a platform should be using flexbile and clear on what is >>>>> >>>> doing, >>>> >>>>> so "user space" can customize on top of it. >>>>> >>>>> >>>>> On Wed, Jun 4, 2014 at 12:44 PM, Terence M. Bandoian < >>>>> >>>> tere...@tmbsw.com> >>> >>>> wrote: >>>>> >>>>> This is helpful. Thank you for posting this, Carlos. I have a >>>>>> >>>>> couple >>> >>>> of >>>> >>>>> related questions. >>>>>> >>>>>> The config files I've used iOS and Android are significantly >>>>>> >>>>> different >>> >>>> for >>>>> >>>>>> the same project. Is combining everything for all platforms into one >>>>>> config.xml recommended? >>>>>> >>>>>> What cordova commands cause the www folder to be copied to a >>>>>> >>>>> platforms >>> >>>> directory? My workflow for iOS/Xcode is typically (similar for >>>>>> Android/Eclipse): >>>>>> >>>>>> - add/build iOS platform using cordova >>>>>> - edit, build, test iteratively in Xcode using platforms/ios >>>>>> >>>>> directory >>> >>>> Xcode doesn't copy from the outer www directory when it builds. >>>>>> >>>>> Should >>> >>>> it? >>>>> >>>>>> All of the files added to the Xcode project are in the platforms/ios >>>>>> directory. >>>>>> >>>>>> -Terence >>>>>> >>>>>> >>>>>> >>>>>> On 6/4/2014 10:10 AM, Carlos Santana wrote: >>>>>> >>>>>> I think regardless how much sugar we use to make it easy, I think >>>>>>> >>>>>> the >>> >>>> under >>>>>>> the hood foundation/architecture should be something like: >>>>>>> >>>>>>> LocalProject/www/ >>>>>>> LocalProject/config.xml >>>>>>> LocalProject/package.json >>>>>>> LocalProject/node_module/.bin/cordova >>>>>>> >>>>>>> config.xml (manages the cordova app) >>>>>>> package.json (manages the cordova project) >>>>>>> >>>>>>> pacakge.json (will specify all dependencies and npm will take care >>>>>>> >>>>>> of >>> >>>> fulfill them) >>>>>>> { >>>>>>> cordova: ">3.6", >>>>>>> cordova-ios: "3.6.1", >>>>>>> cordova-android: "3.6.2", >>>>>>> cordova-plugin-device: "*", >>>>>>> cordova-plugin-file: "^0.2.4" >>>>>>> } >>>>>>> npm install will take care of making everything available locally. >>>>>>> >>>>>>> I know that we don't have plugins in npm, but something to think >>>>>>> >>>>>> about, >>>> >>>>> in >>>>> >>>>>> terms of just a secondary repository to download the files and >>>>>>> >>>>>> caching. >>>> >>>>> a global @cordova-cli, can be available like grunt-cli, to look >>>>>>> >>>>>> first >>> >>>> in >>>> >>>>> local directory (i.e. findup) >>>>>>> >>>>>>> like someone mentioned npm installs hooks can run the "cordova >>>>>>> >>>>>> platform >>>> >>>>> add" >>>>>>> >>>>>>> this way minimal set of files can be put a dev repo, and reproduce >>>>>>> >>>>>> by >>> >>>> another developer very easy both getting same resulting project. >>>>>>> >>>>>>> git clone https://github.com/myuser/cordovapp && cd cordovapp && >>>>>>> >>>>>> npm >>> >>>> install && cordova run android >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Jun 3, 2014 at 6:35 PM, Terence M. Bandoian < >>>>>>> >>>>>> tere...@tmbsw.com> >>>> >>>>> wrote: >>>>>>> >>>>>>> I still consider myself a relative newcomer to Cordova but, from a >>>>>>> >>>>>>>> development standpoint, it would be easiest for me if I could >>>>>>>> >>>>>>> manage >>> >>>> each >>>>> >>>>>> platform of a project independently - including plugins. Creating >>>>>>>> >>>>>>> a >>> >>>> parallel project to make sure that the plugins and Cordova base >>>>>>>> >>>>>>> don't >>> >>>> change for one platform while I work on another isn't ideal but it >>>>>>>> >>>>>>> isn't >>>>> >>>>>> completely unmanageable either. It just makes the workflow a >>>>>>>> >>>>>>> little >>> >>>> more >>>>> >>>>>> complex. >>>>>>>> >>>>>>>> -Terence >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 6/3/2014 7:12 PM, Michal Mocny wrote: >>>>>>>> >>>>>>>> We don't do platform-plugin version matching *at all* today. >>>>>>>> >>>>>>> Everyone >>>> >>>>> uses >>>>>>>>> the latest plugins and any platform version they want, and its >>>>>>>>> >>>>>>>> been >>> >>>> "fine". >>>>>>>>> So using different platform versions isn't as hard as you guys >>>>>>>>> >>>>>>>> are >>>> >>>>> making >>>>>>>>> it out to be. >>>>>>>>> >>>>>>>>> Still, I've already said its not necessarily a complexity that >>>>>>>>> >>>>>>>> needs >>> >>>> to >>>>> >>>>>> be >>>>>>>>> addressed in a world where you can create multiple projects and >>>>>>>>> >>>>>>>> use >>> >>>> --link-to or whatever, so long as your platforms aren't installed >>>>>>>>> globally. >>>>>>>>> >>>>>>>>> >>>>>>>>> Anyway, thanks for posting your instructions Brian/Tommy. As I >>>>>>>>> mentioned >>>>>>>>> it would be, thats a different workflow than we have now. I'm >>>>>>>>> >>>>>>>> going >>> >>>> to >>>>> >>>>>> sleep on it before I comment, but it certainly isn't just like >>>>>>>>> >>>>>>>> "You >>> >>>> know >>>>> >>>>>> how we do it today". >>>>>>>>> >>>>>>>>> -Michal >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Jun 3, 2014 at 7:59 PM, tommy-carlos williams < >>>>>>>>> to...@devgeeks.org >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> I don’t think you really can forget about plugins for a second. >>>>>>>>> >>>>>>>>> In my personal opinion, the entire ./platforms folder should be a >>>>>>>>>> >>>>>>>>> build >>>>> >>>>>> artefact. If you want to freeze iOS, then use a branch or a new >>>>>>>>>> >>>>>>>>> clone >>>> >>>>> of >>>>>>>>>> the project. >>>>>>>>>> >>>>>>>>>> It’s not that I can think of no scenarios where supporting >>>>>>>>>> >>>>>>>>> multiple >>> >>>> platform versions would be needed, it’s just that I think it’s >>>>>>>>>> needlessly >>>>>>>>>> complex vs using a dev workflow to solve those problems. >>>>>>>>>> >>>>>>>>>> I already version cordova within a project… I have a local >>>>>>>>>> >>>>>>>>> version >>> >>>> of >>>> >>>>> cordova installed into ./node_modules for each project and use >>>>>>>>>> >>>>>>>>> Grunt >>>> >>>>> to >>>>> >>>>>> call ./node_modules/.bin/cordova rather than the global cordova >>>>>>>>>> >>>>>>>>> cli. >>>> >>>>> On 4 June 2014 at 9:46:29, Terence M. Bandoian ( >>>>>>>>>> >>>>>>>>> tere...@tmbsw.com) >>> >>>> wrote: >>>>>>>>>> >>>>>>>>>> Forgetting about plugins for a second, what if: >>>>>>>>>> >>>>>>>>>> - I complete a project for iOS >>>>>>>>>> - six months later the client decides to port to Android and: >>>>>>>>>> - I want the latest fixes for Android >>>>>>>>>> - I want to keep the iOS version frozen for the time being >>>>>>>>>> >>>>>>>>>> I would expect releases for each platform to be on different >>>>>>>>>> >>>>>>>>> schedules. >>>>> >>>>>> -Terence >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 6/3/2014 6:17 PM, Michal Mocny wrote: >>>>>>>>>> >>>>>>>>>> Most plugins will work across a wide range of platform versions, >>>>>>>>>> >>>>>>>>> so >>>> >>>>> often >>>>>>>>>>> it would work to have disparate platform versions even with >>>>>>>>>>> >>>>>>>>>> plugins. >>>> >>>>> However, I do concede that in general this isn't a complexity we >>>>>>>>>>> >>>>>>>>>> focus >>>>> >>>>>> on. >>>>>>>>>>> >>>>>>>>>> Interested in your thoughts about the other points. >>>>>>>>>> >>>>>>>>>>> -Michal >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Tue, Jun 3, 2014 at 7:07 PM, tommy-carlos williams < >>>>>>>>>>> >>>>>>>>>>> to...@devgeeks.org> >>>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> You can’t have version x of a plugin for iOS and version y of >>>>>>>>>>> >>>>>>>>>> that >>>> >>>>> same >>>>>>>>>>> >>>>>>>>>>> plugin for Android, so multiple platform versions seems like a >>>>>>>>>>>> >>>>>>>>>>>> complexity >>>>>>>>>>>> >>>>>>>>>>> for complexity’s sake. >>>>>>>>>>> >>>>>>>>>>> It’s true that different apps need to support different >>>>>>>>>>>> >>>>>>>>>>> platform >>> >>>> versions, >>>>>>>>>>>> >>>>>>>>>>> but I would suspect that the greatest majority of those would >>>>>>>>>>> >>>>>>>>>> want >>> >>>> the >>>>> >>>>>> same >>>>>>>>>>> version of iOS and Android in app x. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On 4 June 2014 at 9:04:42, Brian LeRoux (b...@brian.io) wrote: >>>>>>>>>>>> >>>>>>>>>>>> That is the thing: you do not EVER want to have disparate >>>>>>>>>>>> >>>>>>>>>>> versions >>>> >>>>> of >>>>> >>>>>> platforms. Plugins negate this potential fantasy. >>>>>>>>>>>> >>>>>>>>>>>> You want version locked deps. You want to use package.json to >>>>>>>>>>>> >>>>>>>>>>> do >>> >>>> that >>>>> >>>>>> b/c >>>>>>>>>>>> >>>>>>>>>>> that is what the runtime we use has standardized itself on. >>>>>>>>>>> >>>>>>>>>>> On Tue, Jun 3, 2014 at 1:12 PM, Terence M. Bandoian < >>>>>>>>>>>> tere...@tmbsw.com >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> A typical use case might be: >>>>>>>>>>>> >>>>>>>>>>>> -project1 >>>>>>>>>>>>> -project1-ios >>>>>>>>>>>>> -project1-android >>>>>>>>>>>>> -project1-windows >>>>>>>>>>>>> ... >>>>>>>>>>>>> -projectN >>>>>>>>>>>>> -projectN-ios >>>>>>>>>>>>> -projectN-android >>>>>>>>>>>>> -projectN-windows >>>>>>>>>>>>> >>>>>>>>>>>>> with a different platform version for each sub-project. >>>>>>>>>>>>> >>>>>>>>>>>>> Would CLI be installed globally? Locally for each sub-project? >>>>>>>>>>>>> Would a >>>>>>>>>>>>> project-platform have to be re-built if a plugin were added? >>>>>>>>>>>>> >>>>>>>>>>>>> -Terence >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 6/3/2014 1:47 PM, Michal Mocny wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Okay, so I think that implies: >>>>>>>>>>>>> >>>>>>>>>>>>> (a) CLI versions tied to very specific platform versions ==> >>>>>>>>>>>>>> >>>>>>>>>>>>> to >>> >>>> switch >>>>>>>>>>>>>> platform versions you must switching CLI versions ==> >>>>>>>>>>>>>> >>>>>>>>>>>>> switching >>> >>>> one >>>>> >>>>>> platform version switches all platform versions. >>>>>>>>>>>>>> - Andrew pointed out this is currently the case, and is a >>>>>>>>>>>>>> >>>>>>>>>>>>> problem >>>> >>>>> that >>>>>>>>>>>>>> leads to users not updating CLI as often as they otherwise >>>>>>>>>>>>>> >>>>>>>>>>>>> would >>>> >>>>> - I think this basically implies platforms cannot be >>>>>>>>>>>>>> >>>>>>>>>>>>> independently >>>>> >>>>>> versioned (sure the semver numbers may differ, but for all >>>>>>>>>>>>>> practical >>>>>>>>>>>>>> purposes, you would use platforms from the same release date, >>>>>>>>>>>>>> >>>>>>>>>>>>> based >>>>> >>>>>> on >>>>>>>>>>>>>> >>>>>>>>>>>>>> CLI >>>>>>>>>>>>>> >>>>>>>>>>>>> version). >>>>>>>>>>>>> >>>>>>>>>>>>> (b) Require apps to depend on specific CLI version, assuming >>>>>>>>>>>>>> >>>>>>>>>>>>> you >>>> >>>>> mean >>>>>>>>>>>>>> >>>>>>>>>>>>>> with >>>>>>>>>>>>>> >>>>>>>>>>>>> a local package.json: >>>>>>>>>>>>> >>>>>>>>>>>>> - Now all cordova projects must be node projects, which they >>>>>>>>>>>>>> currently >>>>>>>>>>>>>> >>>>>>>>>>>>>> are >>>>>>>>>>>>>> >>>>>>>>>>>>> not. >>>>>>>>>>>>> >>>>>>>>>>>>> - Currently the cordova-cli creates apps, so we have a >>>>>>>>>>>>>> >>>>>>>>>>>>> globally >>> >>>> installed >>>>>>>>>>>>>> >>>>>>>>>>>>> bootstrapping cordova-cli, and a locally installed specific >>>>>>>>>>>>> >>>>>>>>>>>> version >>>>> >>>>>> cordova-cli, a-la grunt/gulp. (this idea was thrown around >>>>>>>>>>>>>> >>>>>>>>>>>>> before). >>>>> >>>>>> - Quite a dramatic change for cordova workflow, surely larger >>>>>>>>>>>>>> >>>>>>>>>>>>> than >>>>> >>>>>> the >>>>>>>>>>>>>> current proposal. >>>>>>>>>>>>>> - Or we drop cordova-cli entirely and just publish grunt/gulp >>>>>>>>>>>>>> plugins >>>>>>>>>>>>>> >>>>>>>>>>>>>> to >>>>>>>>>>>>>> >>>>>>>>>>>>> "add cordova" to your existing web app. Thats an even more >>>>>>>>>>>> >>>>>>>>>>> radical >>>> >>>>> departure and significant work. >>>>>>>>>>>> >>>>>>>>>>>>> -Michal >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Tue, Jun 3, 2014 at 1:58 PM, Brian LeRoux <b...@brian.io> >>>>>>>>>>>>>> >>>>>>>>>>>>> wrote: >>>> >>>>> No, at least not how I'd see it done. >>>>>>>>>>>>>> >>>>>>>>>>>>>> 1.) Updating is important. Staying current: encouraged. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2.) I'd make my App depend on a specific CLI version. I'd >>>>>>>>>>>>>>> >>>>>>>>>>>>>> call >>> >>>> into >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> that >>>>>>>>>>>>>>> >>>>>>>>>>>>>> using npm scripts. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> On Tue, Jun 3, 2014 at 10:48 AM, Michal Mocny < >>>>>>>>>>>>>>> mmo...@chromium.org> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thinking it through, if cordova platforms are deps of the >>>>>>>>>>>>>>> >>>>>>>>>>>>>> CLI, >>> >>>> to >>>>> >>>>>> install a >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> specific version you wouldn't just do: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> npm install -g cordova-ios@3.4.1 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> you would actually need to: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> cd $(npm config get prefix)/lib/node_modules/cordova >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> npm install --save cordova-ios@3.4.1 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ..and then remember to do that again whenever you `npm >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> update >>>>> >>>>>> -g` >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ..and its harder to have multiple platform versions for >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> different >>>>> >>>>>> projects >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> (questionable if this is useful for devs outside of >>>>>>>>>>>>>>> >>>>>>>>>>>>>> cordova >>> >>>> contributors, >>>>>>>>>>>>>>>> but may be useful at last test upgrades when we ship new >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> platform >>>>> >>>>>> versions). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -Michal >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Tue, Jun 3, 2014 at 1:28 PM, Brian LeRoux <b...@brian.io> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> wrote: >>>>> >>>>>> NIH: not invented here >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Tue, Jun 3, 2014 at 10:17 AM, Andrew Grieve < >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> agri...@chromium.org >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>> On Tue, Jun 3, 2014 at 12:19 PM, Brian LeRoux <b...@brian.io> >>>>>>>>>>>> >>>>>>>>>>> wrote: >>>> >>>>> Actually that was >0 LOC which is a fine argument if you >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ask >>>> >>>>> me. >>>>>>>>>>>>>>>>>> And >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> we >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> both know there is much more to it than just that. >>>>>>>>>>>>>>>> lazy_load…for >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> example. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> If you're concerned about code, there is a tonne of much >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> lower-hanging >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> fruit. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Bundling platforms is bundling a dep that we require to >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> operate. >>>>> >>>>>> We >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> do >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> not >>>>>>>>>>>> >>>>>>>>>>>>> require plugins to operate. You cannot build a project >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> without >>>>> >>>>>> having a >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> platform and, indeed, you probably want more than one. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I don't require blackberry to create an iOS project. But >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I >>> >>>> do >>>> >>>>> require >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> some >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> plugins. We use "npm cache add" to download plugins, I >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> don't >>>> >>>>> see >>>>>>>>>>>>>>>>> how >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> platforms would not work just as easily. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Agree that we need discreet versioning: hence why I'm >>>>>>>>>>>>>>>>>> advocating >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> we >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> use >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> well understood, maintained, and effectively standard system >>>>>>>>>>>> >>>>>>>>>>> for >>> >>>> doing >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> this. We do not need NIH dependencies that is what >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> package.json is >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> for! >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I don't know what NIH dependencies are. Googling >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> suggests >>> >>>> you're >>>>>>>>>>>>>>>>> talking >>>>>>>>>>>>>>>>> about drugs... >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> We *are* using npm for downloading, we're just not making >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> the >>>> >>>>> user >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> type >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> it >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> directly. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Mark's approach also avoids the "what-if" cases where >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> what's >>>> >>>>> in >>>>> >>>>>> your >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> node_modules might not match what's in your platforms/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Does what Mark has implemented not address a use-case of >>>>>>>>>>>> yours? >>>>>>>>>>>> >>>>>>>>>>>>> Or >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> are >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> we >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> going back & forth over personal preference? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Tue, Jun 3, 2014 at 9:07 AM, Andrew Grieve < >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> agri...@chromium.org> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Tue, Jun 3, 2014 at 11:34 AM, Brian LeRoux <b...@brian.io >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Andrew, you misunderstand. I am talking about bundling >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> platforms >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> directly >>>>>>>>>>>>>>>>>> as dependencies of the CLI. >>>>>>>>>>>>>>>>>> A trivial example: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> CLI >>>>>>>>>>>>>>>>>>>>> '-ios >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Wherein, CLI declares the precise version of the >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> platform >>>> >>>>> it >>>>> >>>>>> uses. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> We >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> could >>>>>>>>>>>>>>>>>> wildcard. I don't know that we want or need to do that. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> It would have identical semantics to today except the >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> download >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> penalty >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> happens up front. (We can remove lazy_load logic. We >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> don't >>>> >>>>> have >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> maintain >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> our own dependency manifests and caches. LESS code: good >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> thing.) >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Let me paste the code for doing our own caching for >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> you: >>> >>>> cordova_npm: function lazy_load_npm(platform) { >>>>>>>>>>>>>>>>>> if (!(platform in platforms)) { >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> return Q.reject(new Error('Cordova library "' + >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> platform >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> + >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> '" >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> not recognized.')); >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> var pkg = 'cordova-' + platform + '@' + >>>>>>>>>>>>>>>>>>>> platforms[platform].version; >>>>>>>>>>>>>>>>>>>> return Q.nfcall( npm.load, {cache: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> path.join(util.libDirectory, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 'npm_cache') }) >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> .then(function() { >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> return Q.ninvoke(npm.commands, 'cache', ['add', >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> pkg]); >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> }).then(function(info) { >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> var pkgDir = path.resolve(npm.cache, info.name, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> info.version, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 'package'); >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> return pkgDir; >>>>>>>>>>>>>>>>>>>> }); >>>>>>>>>>>>>>>>>>>> }, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> There's really no "amount of code" argument here. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Adding platforms at a specific version would mean >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> having >>> >>>> a >>>> >>>>> specific >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> version >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> of the CLI. Yes: this is way better! Explicit >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> dependencies >>> >>>> is >>>> >>>>> the >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> best >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> way >>>>>>>>>>>>>>>>>> to work w/ the small modules thing. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Bundling platforms with CLI would be like bundling all >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> of >>>> >>>>> the >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>
