cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: adding platforms to npm for dependency sanity
Date Tue, 03 Jun 2014 02:14:31 GMT
Here's both flows as I understand them:

Direct NPM flow:
# Downloads platform source into node_modules
npm install cordova-ios@3.4.0 --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 ios@3.4.0

- 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 <b@brian.io> wrote:

> Eventually, yes. (Sort of how Grunt works now.)
>
>
> On Mon, Jun 2, 2014 at 5:52 PM, Terence M. Bandoian <terence@tmbsw.com>
> 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 cordova-ios@3.5.0".
> >>
> >> 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 <iclelland@chromium.org>
> >> 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 <agrieve@chromium.org>
> >>> wrote:
> >>>
> >>>  Not sure what your question is.
> >>>>
> >>>>
> >>>> On Mon, Jun 2, 2014 at 2:03 PM, Brian LeRoux <b@brian.io> wrote:
> >>>>
> >>>>  *ahem
> >>>>>
> >>>>>
> >>>>> On Wed, May 28, 2014 at 11:20 AM, Brian LeRoux <b@brian.io>
wrote:
> >>>>>
> >>>>>  npm i cordova-ios@3.5.0
> >>>>>>
> >>>>>> Right?
> >>>>>> On May 27, 2014 11:06 PM, "Andrew Grieve" <agrieve@chromium.org>
> >>>>>>
> >>>>> 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 <
> kamrik@google.com
> >>>>>>> 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)
> >>>>
> >>>>> <
> >>>>>
> >>>>>> panarasi@microsoft.com> 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: brian.leroux@gmail.com [mailto:brian.leroux@gmail.com]
On
> >>>>>>>>>
> >>>>>>>> Behalf
> >>>>>>>
> >>>>>>>> Of
> >>>>>>>>
> >>>>>>>>> Brian LeRoux
> >>>>>>>>> Sent: Tuesday, May 27, 2014 2:20 PM
> >>>>>>>>> To: dev@cordova.apache.org
> >>>>>>>>> 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!
> >>>>>>>>>
> >>>>>>>>>
> >
>

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