cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: adding platforms to npm for dependency sanity
Date Wed, 04 Jun 2014 22:48:16 GMT
Plugins have to target specific versions. [1] Core plugins, our org.apache
plugins, are cross platform. [2]

This is not conceptual but the current reality and a correct software
practice.

[1]
https://github.com/apache/cordova-plugin-inappbrowser/blob/master/plugin.xml#L33
[2] https://github.com/apache/cordova-plugin-inappbrowser/tree/master/src


On Wed, Jun 4, 2014 at 5:32 PM, Terence M. Bandoian <terence@tmbsw.com>
wrote:

> Why is having different versions of platforms a recipe for disaster?
>
> -Terence
>
>
> On 6/4/2014 4:29 PM, Brian LeRoux wrote:
>
>> As discussed: having different versions of platforms and plugins is a
>> recipe for disaster. The design choice of version locking is deliberate to
>> avoid that. I'm going to ignore the ramble about grunt, etc. I'm not
>> advocating for that nor am I interested in javascript build library
>> fashion. Those things are not problems we seek to solve here.
>>
>> Also: this is not talk. Its building consensus to *continue* the work
>> being
>> done into a direction that everyone feels good about. The alternative is
>> patchbombing and a massive delete of google employee commits which is
>> probably not productive.
>>
>>
>>
>> On Wed, Jun 4, 2014 at 2:16 PM, Andrew Grieve <agrieve@chromium.org>
>> wrote:
>>
>>  Brian's and Carlos' examples have a very important difference:
>>>
>>> Brian's: platforms are dependencies of CLI
>>> Carlos': platforms are siblings of CLI in top-level package.json
>>>
>>> With Carlos', the user can easily control versions of the platforms,
>>> which
>>> is great. You could just as easily put plugins in there now that npm
>>> supports multiple registries as well.
>>>
>>> I don't think you'd need CLI at all with this setup. Just use plugman &
>>> grunt & recreate your project on every build. I think it's a nice
>>> workflow,
>>> but I'm afraid that dramatically changing out documented workflow again
>>> so
>>> soon would be an unwelcome change. I also think it'd be a good amount of
>>> work to make our tools smart enough to work alongside npm in a way that
>>> isn't confusing (e.g. if we're recreating every time, we'll need to speed
>>> it up a lot. If not, then you need to tell it when dependencies change).
>>>
>>> My main goal for now is to get to where we can release platforms
>>> independently, but I'm curious if this is all talk or is anyone intending
>>> to do some real exploration in this area?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Jun 4, 2014 at 4:55 PM, Brian LeRoux <b@brian.io> wrote:
>>>
>>>  Here is an example using our current situation. Cordova is versioned [1]
>>>> and the CLI calls are abstracted as npm scripts [2]. If we change to the
>>>> proposed 'versioning platforms using npm' we don't have to download
>>>> platforms, cache them or perform any custom dependency logic.
>>>>
>>>> We will then be well on the path to making the CLI *really* dumb and it
>>>> will only pass calls down to the lib installed in node_modules.
>>>>
>>>> HTH
>>>>
>>>> [1]
>>>>
>>>>
>>>>  https://github.com/brianleroux/cordova-example-
>>> using-npm/blob/master/package.json#L13
>>>
>>>> [2]
>>>>
>>>>
>>>>  https://github.com/brianleroux/cordova-example-
>>> using-npm/blob/master/package.json#L8
>>>
>>>>
>>>> On Wed, Jun 4, 2014 at 1:38 PM, Carlos Santana <csantana23@gmail.com>
>>>> wrote:
>>>>
>>>>  Michal
>>>>>    The grunt plugin and yeoman generator I implemented a long ago. So
>>>>>
>>>> it's
>>>
>>>> implemented on top of what cordova provides.
>>>>>
>>>>> I'm confuse, this is the point I was trying to get that there is "user
>>>>> space" and "cordova platform space", Doing a plugin for yeoman, gulp ,
>>>>> grunt, or the next thing is user space.
>>>>>
>>>>> cordova as a platform should be using flexbile and clear on what is
>>>>>
>>>> doing,
>>>>
>>>>> so "user space" can customize on top of it.
>>>>>
>>>>>
>>>>> On Wed, Jun 4, 2014 at 12:44 PM, Terence M. Bandoian <
>>>>>
>>>> terence@tmbsw.com>
>>>
>>>> wrote:
>>>>>
>>>>>  This is helpful.  Thank you for posting this, Carlos.  I have a
>>>>>>
>>>>> couple
>>>
>>>> of
>>>>
>>>>> related questions.
>>>>>>
>>>>>> The config files I've used iOS and Android are significantly
>>>>>>
>>>>> different
>>>
>>>> for
>>>>>
>>>>>> the same project.  Is combining everything for all platforms into one
>>>>>> config.xml recommended?
>>>>>>
>>>>>> What cordova commands cause the www folder to be copied to a
>>>>>>
>>>>> platforms
>>>
>>>> directory?  My workflow for iOS/Xcode is typically (similar for
>>>>>> Android/Eclipse):
>>>>>>
>>>>>> - add/build iOS platform using cordova
>>>>>> - edit, build, test iteratively in Xcode using platforms/ios
>>>>>>
>>>>> directory
>>>
>>>> Xcode doesn't copy from the outer www directory when it builds.
>>>>>>
>>>>> Should
>>>
>>>> it?
>>>>>
>>>>>>   All of the files added to the Xcode project are in the platforms/ios
>>>>>> directory.
>>>>>>
>>>>>> -Terence
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 6/4/2014 10:10 AM, Carlos Santana wrote:
>>>>>>
>>>>>>  I think regardless how much sugar we use to make it easy, I think
>>>>>>>
>>>>>> the
>>>
>>>> under
>>>>>>> the hood foundation/architecture should be something like:
>>>>>>>
>>>>>>> LocalProject/www/
>>>>>>> LocalProject/config.xml
>>>>>>> LocalProject/package.json
>>>>>>> LocalProject/node_module/.bin/cordova
>>>>>>>
>>>>>>> config.xml (manages the cordova app)
>>>>>>> package.json (manages the cordova project)
>>>>>>>
>>>>>>> pacakge.json (will specify all dependencies and npm will take care
>>>>>>>
>>>>>> of
>>>
>>>> fulfill them)
>>>>>>> {
>>>>>>> cordova: ">3.6",
>>>>>>> cordova-ios: "3.6.1",
>>>>>>> cordova-android: "3.6.2",
>>>>>>> cordova-plugin-device: "*",
>>>>>>> cordova-plugin-file: "^0.2.4"
>>>>>>> }
>>>>>>> npm install will take care of making everything available locally.
>>>>>>>
>>>>>>> I know that we don't have plugins in npm, but something to think
>>>>>>>
>>>>>> about,
>>>>
>>>>> in
>>>>>
>>>>>> terms of just a secondary repository to download the files and
>>>>>>>
>>>>>> caching.
>>>>
>>>>> a global @cordova-cli, can be available like grunt-cli, to look
>>>>>>>
>>>>>> first
>>>
>>>> in
>>>>
>>>>> local directory (i.e. findup)
>>>>>>>
>>>>>>> like someone mentioned npm installs hooks can run the "cordova
>>>>>>>
>>>>>> platform
>>>>
>>>>> add"
>>>>>>>
>>>>>>> this way minimal set of files can be put a dev repo, and reproduce
>>>>>>>
>>>>>> by
>>>
>>>> another developer very easy both getting same resulting project.
>>>>>>>
>>>>>>> git clone https://github.com/myuser/cordovapp && cd cordovapp &&
>>>>>>>
>>>>>> npm
>>>
>>>> install && cordova run android
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jun 3, 2014 at 6:35 PM, Terence M. Bandoian <
>>>>>>>
>>>>>> terence@tmbsw.com>
>>>>
>>>>> wrote:
>>>>>>>
>>>>>>>   I still consider myself a relative newcomer to Cordova but, from a
>>>>>>>
>>>>>>>> development standpoint, it would be easiest for me if I could
>>>>>>>>
>>>>>>> manage
>>>
>>>> each
>>>>>
>>>>>> platform of a project independently - including plugins.  Creating
>>>>>>>>
>>>>>>> a
>>>
>>>> parallel project to make sure that the plugins and Cordova base
>>>>>>>>
>>>>>>> don't
>>>
>>>> change for one platform while I work on another isn't ideal but it
>>>>>>>>
>>>>>>> isn't
>>>>>
>>>>>> completely unmanageable either.  It just makes the workflow a
>>>>>>>>
>>>>>>> little
>>>
>>>> more
>>>>>
>>>>>> complex.
>>>>>>>>
>>>>>>>> -Terence
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 6/3/2014 7:12 PM, Michal Mocny wrote:
>>>>>>>>
>>>>>>>>   We don't do platform-plugin version matching *at all* today.
>>>>>>>>
>>>>>>>   Everyone
>>>>
>>>>> uses
>>>>>>>>> the latest plugins and any platform version they want, and its
>>>>>>>>>
>>>>>>>> been
>>>
>>>> "fine".
>>>>>>>>>     So using different platform versions isn't as hard as you guys
>>>>>>>>>
>>>>>>>> are
>>>>
>>>>> making
>>>>>>>>> it out to be.
>>>>>>>>>
>>>>>>>>> Still, I've already said its not necessarily a complexity that
>>>>>>>>>
>>>>>>>> needs
>>>
>>>> to
>>>>>
>>>>>> be
>>>>>>>>> addressed in a world where you can create multiple projects and
>>>>>>>>>
>>>>>>>> use
>>>
>>>> --link-to or whatever, so long as your platforms aren't installed
>>>>>>>>> globally.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Anyway, thanks for posting your instructions Brian/Tommy.  As I
>>>>>>>>> mentioned
>>>>>>>>> it would be, thats a different workflow than we have now.  I'm
>>>>>>>>>
>>>>>>>> going
>>>
>>>> to
>>>>>
>>>>>> sleep on it before I comment, but it certainly isn't just like
>>>>>>>>>
>>>>>>>> "You
>>>
>>>> know
>>>>>
>>>>>> how we do it today".
>>>>>>>>>
>>>>>>>>> -Michal
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Jun 3, 2014 at 7:59 PM, tommy-carlos williams <
>>>>>>>>> tommy@devgeeks.org
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>    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 (
>>>>>>>>>>
>>>>>>>>> terence@tmbsw.com)
>>>
>>>> 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 <
>>>>>>>>>>>
>>>>>>>>>>>   tommy@devgeeks.org>
>>>>>>>>>>>
>>>>>>>>>>   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 (b@brian.io) 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 <
>>>>>>>>>>>> terence@tmbsw.com
>>>>>>>>>>>> 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 <b@brian.io>
>>>>>>>>>>>>>>
>>>>>>>>>>>>> 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 <
>>>>>>>>>>>>>>> mmocny@chromium.org>
>>>>>>>>>>>>>>> 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 cordova-ios@3.4.1
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>     you would actually need to:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>     cd $(npm config get prefix)/lib/node_modules/cordova
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>  npm install --save cordova-ios@3.4.1
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>    ..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 <b@brian.io>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> wrote:
>>>>>
>>>>>> NIH: not invented here
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   On Tue, Jun 3, 2014 at 10:17 AM, Andrew Grieve <
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>   agrieve@chromium.org
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Tue, Jun 3, 2014 at 12:19 PM, Brian LeRoux <b@brian.io>
>>>>>>>>>>>>
>>>>>>>>>>> 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 <
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>     agrieve@chromium.org>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>  wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Tue, Jun 3, 2014 at 11:34 AM, Brian LeRoux <b@brian.io
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>

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