cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Santana <>
Subject Re: Proposal: remove platform versions from platfroms.js
Date Wed, 23 Jul 2014 21:27:07 GMT
I forgot to mention but agree with suggestion of having a local version of
cordova cli saved in node_modues, and that the default cordova behavior
will be to look first in local node_modules for cordova cli and if it found
use that one, if not then use global one. same as grunt-cli

On Wed, Jul 23, 2014 at 5:21 PM, Carlos Santana <>

> +1 on removing the pining
> Can we at least record what's get's installed in a single place?
> This will help if someone is trying to debug a problem, it will be easy to
> tell what are the components and their levels being use.
> Meaning a the minimum recording platforms, plugins, and latest cli version
> used on the project.
> Meaning every time you add a platform or plugin update cordova.json,
> everytime you run a cordova command like "cordova prepare"
> cordova.json
> {
> cordova: "3.7.1-0.3.7",
> platforms:[{name:"cordova-ios",version:"3.6.1"},{name:"cordova-blackberry",version:"3.7"}]
> plugins:[{id:"org.apache.cordova.console",version:"0.1.2"},{id:"",version:"0.1.1"}]
> }
> I prefer cordova.json on the root, and if not present look for a "cordova"
> object in package.json
> After this is done, we can discuss how this information can be use by the
> tool if at all like implementing a "cordova install" that reads the file,
> or a "cordova outdated" that reads the file, and so on.. of course without
> re implementing the wheel and leveraging "npm" and "node_modules" directory
> Also work towards making the cli so so unaware about the platforms, that
> adding a new platform "cordova-xphone" the cli will not need to change.
> Then the problem about what cli version works with what version of the
> platform becomes a mute point.
> On Wed, Jul 23, 2014 at 4:50 PM, Michal Mocny <> wrote:
>> I think Mark summarizes my thoughts as well.
>> We're overdue brainstorming what we want cordova workspaces to look like
>> (package.json, app manifests / config files, grunt/gulp integration,
>> browserify, directory structure..).  I don't think even the full hour on
>> this weeks hangout would suffice for this, so we should probably organize
>> something specifically for this topic for another date.  I don't think we
>> should be making any significant changes to users' cli workflow until we
>> figure out where we actually want to end up (and worry thats what we are
>> doing with the current package.json proposals).
>> For the purpose of this week we should have the goal of figuring out:
>> - What behaviour do users expect (Please not "what is the current
>> behaviour
>> and why it cannot change")
>> - How to simplify releasing platforms
>> - How/when to (properly) pin down versions of all cordova bits
>> -Michal
>> On Wed, Jul 23, 2014 at 4:30 PM, Mark Koudritsky <>
>> wrote:
>> > Part of the discussion is release flexibility vs predictability. My main
>> > problem is that currently we have neither. By default CLI downloads
>> pinned
>> > versions of platforms but latest versions of plugins.
>> >
>> > Changing the concept of corodva project to something managed by npm is
>> an
>> > interesting idea but it requires much much more than just adding a
>> > package.json file and is not a short term thing. I think it deserves a
>> > separate discussion.
>> >
> --
> Carlos Santana
> <>

Carlos Santana

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message