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
