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 <to...@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 <tere...@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 <mmo...@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 <agri...@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 <
agri...@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
plugins
with
CLI, or like bundling every npm module with npm.
Devs need to be able to try out platforms at different versions.
We
should
not do anything that keeps users clinging to old versions of CLI
(e.g.
they
do this now because they don't want to update to new platforms)
On Mon, Jun 2, 2014 at 7:34 PM, Michal Mocny <
mmo...@chromium.org>
wrote:
On Mon, Jun 2, 2014 at 10:14 PM, Andrew Grieve <
agri...@chromium.org
wrote:
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
To be fair, I think with Brian's suggestion, platform add FOO
would
by
default look in node_modules so you wouldn't be explicit
about
it,
and
also
the default cordova project package.json would depend on all
the
latest
versions of each platform, so the flows would actually be:
cordova create Foo && cd Foo
npm install
npm install cordova-ios@3.4 --save
cordova platform add android
cordova platform add ios
# crazy idea? use npm post-install hooks to auto-run
create/upgrade
so
you usually don't need above two lines?
Compared to:
cordova create Foo && cd Foo
cordova platform add android
cordova platform add ios@3.4
I think #2 is enough better that its not worth changing.
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 <
tere...@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 <
iclell...@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 <
agri...@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" <
agri...@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
<
kam...@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)
<
panar...@microsoft.com> wrote:
+1. This will also be a step towards releasing
platforms
independently.
Will the CLI have a semver like dependency on
