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 <agri...@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 <csantan...@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 <
tere...@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 <
tere...@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 <
to...@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 (
tere...@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 <
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
--
Carlos Santana
<csantan...@gmail.com>
