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 <[email protected]> wrote: > +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:"com.ibm.myplugin",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 <[email protected]> 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 <[email protected]> >> 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 > <[email protected]> > -- Carlos Santana <[email protected]>
