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 ([email protected]) 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 <[email protected]>  
> 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 ([email protected]) 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 <[email protected]>  
>> 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 <[email protected]> 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 <[email protected]>  
>>>>> 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 [email protected]  
>>>>>>>  
>>>>>> you would actually need to:  
>>>>>>  
>>>>>>> cd $(npm config get prefix)/lib/node_modules/cordova  
>>>>>>> npm install --save [email protected]  
>>>>>>>  
>>>>>> ..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 <[email protected]> wrote:  
>>>>>>  
>>>>>> NIH: not invented here  
>>>>>>>  
>>>>>>>  
>>>>>>> On Tue, Jun 3, 2014 at 10:17 AM, Andrew Grieve <[email protected]  
>>>>>>> wrote:  
>>>>>>>  
>>>>>>> On Tue, Jun 3, 2014 at 12:19 PM, Brian LeRoux <[email protected]> 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 <  
>>>>>>>>>  
>>>>>>>> [email protected]>  
>>>>>> wrote:  
>>>>>>>>> On Tue, Jun 3, 2014 at 11:34 AM, Brian LeRoux <[email protected]>  
>>>>>>>>> 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  
>>>>>>>>> plugins  
>>>>>>> with  
>>>>>>>>>> CLI, or like bundling every npm module with npm.  
>>>>>>>>>>  
>>>>>>>>>> Devs need to be able to try out platforms at different versions.  
>>>>>>>>>>  
>>>>>>>>> We  
>>>>>> should  
>>>>>>>>>> not do anything that keeps users clinging to old versions of CLI  
>>>>>>>>>>  
>>>>>>>>> (e.g.  
>>>>>>>> they  
>>>>>>>>>> do this now because they don't want to update to new platforms)  
>>>>>>>>>>  
>>>>>>>>>>  
>>>>>>>>>>  
>>>>>>>>>>  
>>>>>>>>>>>  
>>>>>>>>>>> On Mon, Jun 2, 2014 at 7:34 PM, Michal Mocny <  
>>>>>>>>>>>  
>>>>>>>>>> [email protected]>  
>>>>>>> wrote:  
>>>>>>>>>>> On Mon, Jun 2, 2014 at 10:14 PM, Andrew Grieve <  
>>>>>>>>>>> [email protected]  
>>>>>>>>> wrote:  
>>>>>>>>>>>> Here's both flows as I understand them:  
>>>>>>>>>>>>> Direct NPM flow:  
>>>>>>>>>>>>> # Downloads platform source into node_modules  
>>>>>>>>>>>>> npm install [email protected] --save  
>>>>>>>>>>>>> # Runs the create script and installs plugins to create  
>>>>>>>>>>>>>  
>>>>>>>>>>>> platforms/ios  
>>>>>>>>>> cordova platform add ios --path=node_modules/cordova-ios  
>>>>>>>>>>>>> To be fair, I think with Brian's suggestion, platform add FOO  
>>>>>>>>>>> would  
>>>>>>>> by  
>>>>>>>>>> default look in node_modules so you wouldn't be explicit  
>>>>>>>>>>> about  
>>>>>> it,  
>>>>>>>> and  
>>>>>>>>>> also  
>>>>>>>>>>>> the default cordova project package.json would depend on all  
>>>>>>>>>>>>  
>>>>>>>>>>> the  
>>>>>>> latest  
>>>>>>>>>> versions of each platform, so the flows would actually be:  
>>>>>>>>>>>>> cordova create Foo && cd Foo  
>>>>>>>>>>>>> npm install  
>>>>>>>>>>>>> npm install [email protected] --save  
>>>>>>>>>>>>> cordova platform add android  
>>>>>>>>>>>>> cordova platform add ios  
>>>>>>>>>>>>> # crazy idea? use npm post-install hooks to auto-run  
>>>>>>>>>>>>>  
>>>>>>>>>>>> create/upgrade  
>>>>>>>>> so  
>>>>>>>>>>> you usually don't need above two lines?  
>>>>>>>>>>>> Compared to:  
>>>>>>>>>>>>  
>>>>>>>>>>>>> cordova create Foo && cd Foo  
>>>>>>>>>>>>> cordova platform add android  
>>>>>>>>>>>>> cordova platform add [email protected]  
>>>>>>>>>>>>>  
>>>>>>>>>>>> I think #2 is enough better that its not worth changing.  
>>>>>>>>>>>>  
>>>>>>>>>>>>  
>>>>>>>>>>>> Cordova-to-npm flow (as Mark's implemented):  
>>>>>>>>>>>>> # Runs "npm cache add cordova-ios", then runs create script  
>>>>>>>>>>>>>  
>>>>>>>>>>>> from  
>>>>>>>> ~/cache/cordova-ios/bin/create  
>>>>>>>>>>>>> cordova platform add [email protected]  
>>>>>>>>>>>>>  
>>>>>>>>>>>>> - In both flows: we use npm to do all of the heavy lifting  
>>>>>>>>>>>>> - In both flows: the npm module is cached in your home  
>>>>>>>>>>>>>  
>>>>>>>>>>>> directory  
>>>>>>>> - In both flows?: we store the plugins & platforms  
>>>>>>>>>>>> explicitly  
>>>>>> within  
>>>>>>>>>> config.xml (Gorkem's added this)  
>>>>>>>>>>>>> - In flow #1, we have a package.json & a node_modules, in  
>>>>>>>>>>>>>  
>>>>>>>>>>>> #2  
>>>>>> we  
>>>>>>  
>>>>>>> don't.  
>>>>>>>>>>> Why put the onus on the user to fetch the platform source  
>>>>>>>>>>>> when  
>>>>>>> it's  
>>>>>>>>> as  
>>>>>>>>>>> easy  
>>>>>>>>>>>>> as running "npm cache add" under-the-hood?  
>>>>>>>>>>>>>  
>>>>>>>>>>>>>  
>>>>>>>>>>>>> In regards to the idea of using require() on platform  
>>>>>>>>>>>>>  
>>>>>>>>>>>> scripts  
>>>>>> instead  
>>>>>>>>>> of  
>>>>>>>>>>>> subshelling: I think this is tangental to the debate of how  
>>>>>>>>>>>> to  
>>>>>>> fetch  
>>>>>>>>>> the  
>>>>>>>>>>>> platform.  
>>>>>>>>>>>>> In regards to using "npm install" directly when using the  
>>>>>>>>>>>>>  
>>>>>>>>>>>> plugman  
>>>>>>>> workflow:  
>>>>>>>>>>>>> Sounds good to me.  
>>>>>>>>>>>>>  
>>>>>>>>>>>>>  
>>>>>>>>>>>>>  
>>>>>>>>>>>>>  
>>>>>>>>>>>>> On Mon, Jun 2, 2014 at 6:05 PM, Brian LeRoux <[email protected]>  
>>>>>>>>>>>>>  
>>>>>>>>>>>> wrote:  
>>>>>>>> Eventually, yes. (Sort of how Grunt works now.)  
>>>>>>>>>>>>>>  
>>>>>>>>>>>>>> On Mon, Jun 2, 2014 at 5:52 PM, Terence M. Bandoian <  
>>>>>>>>>>>>>>  
>>>>>>>>>>>>> [email protected]  
>>>>>>>>>>>> wrote:  
>>>>>>>>>>>>>> Can multiple versions of a platform be installed  
>>>>>>>>>>>>>> side-by-side?  
>>>>>>>>> -Terence  
>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>> On 6/2/2014 3:04 PM, Michal Mocny wrote:  
>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>> >From original email: "Ideal future CLI uses platforms  
>>>>>>>>>>>>>>> just  
>>>>>>>> like  
>>>>>>>>>> other  
>>>>>>>>>>>>> deps.  
>>>>>>>>>>>>>>>> We lose lazy loading but network and disk is cheap so  
>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>> it  
>>>>>> wasn't  
>>>>>>>>>> really  
>>>>>>>>>>>>> important anyhow."  
>>>>>>>>>>>>>>>> Made me think Brian is proposing adding platforms to  
>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>> cli  
>>>>>> package.json  
>>>>>>>>>>>>> dependencies, and you would have a single global  
>>>>>>>>>>>>>>> install  
>>>>>> cordova-platforms.  
>>>>>>>>>>>>>>>> Then you can override the version with an explicit  
>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>> install  
>>>>>>>> as  
>>>>>>>>>> he  
>>>>>>>>>>  
>>>>>>>>>>> mentions  
>>>>>>>>>>>>>>>> "npm i [email protected]".  
>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>> Personally, I think that workflow could work, and has  
>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>> a  
>>>>>> few  
>>>>>>>> benefits,  
>>>>>>>>>>>>> but  
>>>>>>>>>>>>>>> I'm not sure that option compares well to the  
>>>>>>>>>>>>>>> alternative  
>>>>>>> of  
>>>>>>>  
>>>>>>>> just  
>>>>>>>>>>> lazy  
>>>>>>>>>>>>> loading using npm cache add as Mark has already  
>>>>>>>>>>>>>>> implemented  
>>>>>>>> an  
>>>>>>>>  
>>>>>>>>> experiment  
>>>>>>>>>>>>>>> (anyone interested in this topic should take a look at  
>>>>>>>>>>>>>>> that  
>>>>>>>> patch).  
>>>>>>>>>>>> The steps Brian & Ian outline about how to package  
>>>>>>>>>>>>>>> platforms  
>>>>>>>> for  
>>>>>>>>>> release  
>>>>>>>>>>>>>> to  
>>>>>>>>>>>>>>>> npm are possibly an improvement over the old-style  
>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>> platform-centric  
>>>>>>>>>>>> workflow. Instead of downloading a tarball and  
>>>>>>>>>>>>>>> running  
>>>>>> a  
>>>>>>  
>>>>>>> create  
>>>>>>>>>> script,  
>>>>>>>>>>>>>> you npm install and run a create() function, and that  
>>>>>>>>>>>>>>> can  
>>>>>>> more  
>>>>>>>>> easily  
>>>>>>>>>>>>> be  
>>>>>>>>>>>>>  
>>>>>>>>>>>>>> bundled into other build scripts/boilerplate. For CLI  
>>>>>>>>>>>>>>> workflow,  
>>>>>>>>>> not  
>>>>>>>>>>>> sure  
>>>>>>>>>>>>>>> that there is any real difference (as Jesse says).  
>>>>>>>>>>>>>>> One  
>>>>>> note,  
>>>>>>>>> though:  
>>>>>>>>>>>>> cordova-* platforms are templates for projects, so  
>>>>>>>>>>>>>>> the  
>>>>>> package.json  
>>>>>>>>>>>>> of  
>>>>>>>>>>>>>  
>>>>>>>>>>>>>> the  
>>>>>>>>>>>>>>>> npm package itself shouldn't end up inside projects  
>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>> that  
>>>>>> are  
>>>>>>>> created  
>>>>>>>>>>>> with  
>>>>>>>>>>>>>>> it. I think.  
>>>>>>>>>>>>>>>> -Michal  
>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>> On Mon, Jun 2, 2014 at 3:42 PM, Ian Clelland <  
>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>> [email protected]>  
>>>>>>>>>>>>> wrote:  
>>>>>>>>>>>>>>>> There seems to be some confusion -- I think people  
>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>> are  
>>>>>> talking  
>>>>>>>>>> about  
>>>>>>>>>>>>> different things here, but perhaps it's just me ;)  
>>>>>>>>>>>>>>>>> I thought that Brian's original suggestion was about  
>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>> being  
>>>>>>>> able  
>>>>>>>>>> to  
>>>>>>>>>>>> host  
>>>>>>>>>>>>>> Cordova platforms directly on NPM. That's why each  
>>>>>>>>>>>>>>>> one  
>>>>>> would  
>>>>>>>>> require  
>>>>>>>>>>>>> a  
>>>>>>>>>>>>>  
>>>>>>>>>>>>>> package.json. (which would probably end up in  
>>>>>>>>>>>>>>>>> <project>/platforms/<platform> in a project, but  
>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>> that's  
>>>>>> not  
>>>>>>>> the  
>>>>>>>>>> point  
>>>>>>>>>>>>> of  
>>>>>>>>>>>>>>> it).  
>>>>>>>>>>>>>>>>> As an NPM project, we then would have the opportunity  
>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>> (though  
>>>>>>>>> not  
>>>>>>>>>>> the  
>>>>>>>>>>>>> obligation) to make all of the supporting scripts for  
>>>>>>>>>>>>>>>> each  
>>>>>>>> platform  
>>>>>>>>>>>> (create, build, run, etc) part of the node module,  
>>>>>>>>>>>>>>>> for  
>>>>>> a  
>>>>>>  
>>>>>>> uniform  
>>>>>>>>>>> interface  
>>>>>>>>>>>>>>>>> that doesn't require going through the command line.  
>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>>> It's not about making platforms into CLI dependencies  
>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>> (any  
>>>>>>>> more  
>>>>>>>>>> than  
>>>>>>>>>>>>> plugins are CLI dependencies right now), or about  
>>>>>>>>>>>>>>>> making  
>>>>>>> a  
>>>>>>>  
>>>>>>>> cordova-based  
>>>>>>>>>>>>>>> project into a node package.  
>>>>>>>>>>>>>>>>> If that's right, then I support that -- I'd like the  
>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>> platforms  
>>>>>>>>>> to  
>>>>>>>>>>  
>>>>>>>>>>> be  
>>>>>>>>>>>>> installable through npm, and to be versioned  
>>>>>>>>>>>>>>>> separately,  
>>>>>>> installable  
>>>>>>>>>>>>> separately, and scriptable without having to spawn  
>>>>>>>>>>>>>>>> subshells.  
>>>>>>>>> And if I have it completely wrong, then let me know  
>>>>>>>>>>>>>>>> --  
>>>>>> I'll  
>>>>>>>> just  
>>>>>>>>>>> go  
>>>>>>>>>>>  
>>>>>>>>>>>> back  
>>>>>>>>>>>>>>> to  
>>>>>>>>>>>>>>>>> fixing File bugs ;)  
>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>>> On Mon, Jun 2, 2014 at 3:29 PM, Andrew Grieve <  
>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>> [email protected]>  
>>>>>>>>>>>>> wrote:  
>>>>>>>>>>>>>>>>> Not sure what your question is.  
>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>>>> On Mon, Jun 2, 2014 at 2:03 PM, Brian LeRoux <  
>>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>>> [email protected]>  
>>>>>>>> wrote:  
>>>>>>>>>>>> *ahem  
>>>>>>>>>>>>>>>>>>> On Wed, May 28, 2014 at 11:20 AM, Brian LeRoux <  
>>>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>>>> [email protected]  
>>>>>>>>> wrote:  
>>>>>>>>>>>>> npm i [email protected]  
>>>>>>>>>>>>>>>>>>>> Right?  
>>>>>>>>>>>>>>>>>>>> On May 27, 2014 11:06 PM, "Andrew Grieve" <  
>>>>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>>>>> [email protected]  
>>>>>>>>>>>> wrote:  
>>>>>>>>>>>>>>>>>>> Lazy loading is what will give us the ability to  
>>>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>>>> support  
>>>>>>>> multiple  
>>>>>>>>>>>> versions  
>>>>>>>>>>>>>>>>>>>> of platforms.  
>>>>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>>>>>>> If we don't support users choosing the version of  
>>>>>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>>>>>> the  
>>>>>>> platform  
>>>>>>>>>>>> they  
>>>>>>>>>>>>>> want,  
>>>>>>>>>>>>>>>>>>>> then they will resist updating their version of  
>>>>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>>>>> CLI  
>>>>>> (like  
>>>>>>>>> they  
>>>>>>>>>>> do  
>>>>>>>>>>>>> right  
>>>>>>>>>>>>>>>>>>> now).  
>>>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>>>>>> I'm very keen to allow users to chose their  
>>>>>>>>>>>>>>>>>>>> platform  
>>>>>>> versions,  
>>>>>>>>>>>> just  
>>>>>>>>>>>>>> as  
>>>>>>>>>>>>>>>>>>> they  
>>>>>>>>>>>>>>>>>>> are able to choose their plugin versions.  
>>>>>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>>>>>>> On Tue, May 27, 2014 at 5:57 PM, Mark Koudritsky  
>>>>>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>>>>>> <  
>>>>>> [email protected]  
>>>>>>>>>>>>>>> wrote:  
>>>>>>>>>>>>>>>>>>>>> +1  
>>>>>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>>>>>>>> Steve published (some of?) the platforms on npm  
>>>>>>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>>>>>>> as  
>>>>>> part  
>>>>>>>>> of  
>>>>>>>>>  
>>>>>>>>>> the  
>>>>>>>>>>>> latest  
>>>>>>>>>>>>>>>>>>>> release.  
>>>>>>>>>>>>>>>>>>>> https://www.npmjs.org/package/cordova-android  
>>>>>>>>>>>>>>>>>>>>>> https://www.npmjs.org/package/cordova-ios  
>>>>>>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>>>>>>>> CLI already require()s npm for downloading  
>>>>>>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>>>>>>> plugins  
>>>>>> from  
>>>>>>>>> the  
>>>>>>>>>>> registry.  
>>>>>>>>>>>>>>>>>>>> Extending this to platforms is on my todo list for  
>>>>>>>>>>>>>>>>>> this\next  
>>>>>>>>>> week.  
>>>>>>>>>>>>> The "lazy" part of the loading was about  
>>>>>>>>>>>>>>>>>>>>> caching,  
>>>>>> so  
>>>>>>  
>>>>>>> we  
>>>>>>>>> don't  
>>>>>>>>>>>> lose  
>>>>>>>>>>>>>> it  
>>>>>>>>>>>>>>>>>>>> since  
>>>>>>>>>>>>>>>>>>>> npm does its own caching.  
>>>>>>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>>>>>>>> On Tue, May 27, 2014 at 5:42 PM, Parashuram  
>>>>>>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>>>>>>> Narasimhan  
>>>>>>>> (MS  
>>>>>>>>>> OPEN  
>>>>>>>>>>>>> TECH)  
>>>>>>>>>>>>>>>>>>>> <  
>>>>>>>>>>>>>>>>>>> [email protected]> wrote:  
>>>>>>>>>>>>>>>>>>>>> +1. This will also be a step towards releasing  
>>>>>>>>>>>>>>>>>>>>> platforms  
>>>>>>>>>> independently.  
>>>>>>>>>>>>>>>>>>>>>> Will the CLI have a semver like dependency on  
>>>>>>>>>>>>>>>>>>>>>  
>>  


Reply via email to