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
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 the platform > >>>>>>>>> > >>>>>>>> specified > >>>> > >>>>> somewhere ? Would the cli have to require('npm') and do the > >>>>>>>>> > >>>>>>>> install? > >>>> > >>>>> -----Original Message----- > >>>>>>>>> From: [email protected] [mailto:[email protected]] On > >>>>>>>>> > >>>>>>>> Behalf > >>>>>>> > >>>>>>>> Of > >>>>>>>> > >>>>>>>>> Brian LeRoux > >>>>>>>>> Sent: Tuesday, May 27, 2014 2:20 PM > >>>>>>>>> To: [email protected] > >>>>>>>>> Subject: adding platforms to npm for dependency sanity > >>>>>>>>> > >>>>>>>>> We've discussed this but I'm not sure the whole idea has > >>>>>>>>> > >>>>>>>> crystalized. > >>>>> > >>>>>> My > >>>>>>> > >>>>>>>> proposal (based on previous discussions) below. I'll use iOS as > >>>>>>>>> > >>>>>>>> an > >>> > >>>> example > >>>>>>>> > >>>>>>>>> but this applies to all platforms supported by the CLI. > >>>>>>>>> > >>>>>>>>> First, we'd add two files: > >>>>>>>>> > >>>>>>>>> cordova-ios > >>>>>>>>> |-package.json > >>>>>>>>> '-index.js > >>>>>>>>> > >>>>>>>>> …I don't think I need to describe the utility of package.json > >>>>>>>>> > >>>>>>>> but > >>> > >>>> index.js > >>>>>>>> > >>>>>>>>> would expose programatic library apis: > >>>>>>>>> > >>>>>>>>> module.exports = { create:Function, run:Function, > >>>>>>>>> > >>>>>>>> build:Function, > >>> > >>>> clean:Function, log:Function} > >>>>>>>>> > >>>>>>>>> We then publish to npm. That is it for now. 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. > >>>>>>>>> > >>>>>>>>> Discuss! > >>>>>>>>> > >>>>>>>>> > > >
