On Thu, Jun 5, 2014 at 9:42 AM, Carlos Santana wrote:
> Andrew I agree with everything you said except
> "Things I think are bad ideas:
> - start enforcing that Cordova projects are node projects"
>
> I think Cordova projects is the project that is on your workstation that is
> running node with
A F2F would help this discussion move forward.
I only have two requirements for the F2F:
1. We clarify the topic to be discussed.
This thread has touched a breadth of topics from what's possible today to
semver-major-breaking changes.
2. The F2F time accommodates Tommy Williams.
He's one of th
It actually looks like theres a Cordova Monthly Hangout scheduled for next
Tuesday.
On Thu, Jun 5, 2014 at 1:23 PM, Brian LeRoux wrote:
> 1. Agree w/ Michal: we need to discuss F2F. Want to quickly address some of
> Andrews comments.
>
> > - start enforcing that Cordova projects are node projec
1. Agree w/ Michal: we need to discuss F2F. Want to quickly address some of
Andrews comments.
> - start enforcing that Cordova projects are node projects
Node is a dep already. We could look into painting over it and distributing
raw binary that vendors Node but there's probably no benefit to it.
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.
Please note that arbitrary platform implementations ch
On Wed, Jun 4, 2014 at 5:53 PM, Andrew Grieve wrote:
> Things I think are good ideas:
> - platforms providing an index.js that node can consume. If project scripts
> are not in node, then they can just subshell (or port to node).
> - making it easier to consume CLI from grunt / whatever
> - enabli
My 2cents:
I'm not fundamentally opposed to cordova projects being node projects, but
I don't think adding a package.json to cordova projects as they exist today
is such a good idea.
Namely, (a) we force a certain directory structure and certain command line
usage, and (b) it conflicts with the g
Andrew I agree with everything you said except
"Things I think are bad ideas:
- start enforcing that Cordova projects are node projects"
I think Cordova projects is the project that is on your workstation that is
running node with the tools and npm to manage some of the dependencies and
downloadin
First, thanks to everyone on the list for being so patient and answering
my questions. It is much appreciated.
What I understand so far is that the plugin code for a given platform
must be in sync with that platform. Makes perfect sense. I've also
seen that the core plugin APIs are consiste
Things I think are good ideas:
- platforms providing an index.js that node can consume. If project scripts
are not in node, then they can just subshell (or port to node).
- making it easier to consume CLI from grunt / whatever
- enabling users to do their own fetching rather than CLI doing the
fetc
WRT plugins not being tied to a version of the platforms… We at SpiderOak have
a project that is still stuck at 3.0.0 for precisely that reason.
As for the CLI not being tied to a platform version, that’s also not true.
Don’t know if you have tried it, but using a current version of the CLI wit
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/a
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 ignor
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 th
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 t
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 o
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 us
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 th
Carlos -- not sure, I'll take a look.
Few quick questions perhaps you can answer:
- Does it hide the locations of platforms/ and plugins/ and support
customizing the source of your web assets (perhaps by linking to www/?)
- How do you add platforms / plugins?
On Wed, Jun 4, 2014 at 2:48 PM, Carl
Or a yeoman generator:
https://github.com/csantanapr/generator-cordovacli
I would admit I have not had the bandwidth lately to add more features and
keep them current
On Wed, Jun 4, 2014 at 11:48 AM, Carlos Santana
wrote:
> Micha you mean something like this?
> https://github.com/csantanapr/gr
Micha you mean something like this?
https://github.com/csantanapr/grunt-cordovacli
On Wed, Jun 4, 2014 at 8:29 AM, Michal Mocny wrote:
> On Wed, Jun 4, 2014 at 11:10 AM, Carlos Santana
> wrote:
>
> > I think regardless how much sugar we use to make it easy, I think the
> under
> > the hood fo
Oh whoops, not crazy just excited. Saying YES!! to everything Michal said
in that last msg.
On Wed, Jun 4, 2014 at 11:34 AM, Carlos Santana
wrote:
> YES!! to what? Brian
>
>
> On Wed, Jun 4, 2014 at 11:18 AM, Brian LeRoux wrote:
>
> > YES!!!
> >
> >
> > On Wed, Jun 4, 2014 at 8:45 AM, Michal M
YES!! to what? Brian
On Wed, Jun 4, 2014 at 11:18 AM, Brian LeRoux wrote:
> YES!!!
>
>
> On Wed, Jun 4, 2014 at 8:45 AM, Michal Mocny wrote:
>
> > After sleeping on it, I think if you're going to introduce package.json
> and
> > local installs of cli & platforms, and require node scripts to ma
YES!!!
On Wed, Jun 4, 2014 at 8:45 AM, Michal Mocny wrote:
> After sleeping on it, I think if you're going to introduce package.json and
> local installs of cli & platforms, and require node scripts to manage
> environment, you really may as well go the last mile and replace use of the
> global
Using package.json and npm for dependencies is what those things are
designed for. Those are the conventions of the platform we use: Node. This
IS simpler, following the principle of least surprise: an expected by our
developer audience.
On Jun 4, 2014 8:55 AM, "Marcel Kinard" wrote:
> What Tomm
What Tommy describes here makes some sense.
But what I’m still struggling to see is how the kind of changes in this thread
are a win for Cordova users, in terms such as simplified workflow, a more
predictable consistent tested combination of tools/platforms/plugins, and
especially performing a
After sleeping on it, I think if you're going to introduce package.json and
local installs of cli & platforms, and require node scripts to manage
environment, you really may as well go the last mile and replace use of the
global CLI installation with grunt/gulp plugins. (that sounds interesting,
b
I would add that I'm in agreement with Tommy that "platforms/*" should be
consider build artifacts. this should not be checking into source version
control.
If user changes contents under "platforms/" then it should move any changes
back to "merges/" or write some logic to recover the canges using
On Wed, Jun 4, 2014 at 11: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/
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 (manag
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
I think it's important to point out that with platformed releases
separately, they have to be versioned separately. There will be no such
thing as "Cordova v3.6.0". There will (likely) be cordova-ios@3.6.0,
cordova-android@4.0.0, etc. So either way, platforms will be on different
versions.
About h
..double checked and we do some minimal plugin version checking upon
install offering warnings when they mismatch, but we don't make sure to get
compatible versions from the registry or anything so its quite crude and
limited.
Some numbers: I created a package.json with all the cordova platforms a
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
Terance, with the current proposal thats not possible from within the same
cordova project/directory, but you could easily create a second cordova
project that uses --link-to= to share app assets and use different
CLI/platform versions.
On Tue, Jun 3, 2014 at 7:45 PM, Terence M. Bandoian
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 pla
This is really helpful. Thank you.
-Terence
On 6/3/2014 6:38 PM, tommy-carlos williams wrote:
If the cordova cli was globally installed, but basically a thin wrapper like
grunt-cli…
create:
cordova create foo
cd foo
npm install —save cordova@x.y.z
cordova platform add andr
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
If the cordova cli was globally installed, but basically a thin wrapper like
grunt-cli…
create:
cordova create foo
cd foo
npm install —save cordova@x.y.z
cordova platform add android
cordova platform add ios
cordova create bar
cd bar
npm install —save cordova@x.y.n
cordova plat
old style:
npm i -g cordova
cordova create Foo
cd Foo
cordova platform add ios android
npm update -g cordova
cordova platform update ios android
...tho some might prefer to:
mkdir foo && cd foo && npm init
npm i cordova --save
(and from here modify npm scripts to call into node_modules/cordova/b
I don't see how that can be true.
On Tue, Jun 3, 2014 at 7:23 PM, Brian LeRoux wrote:
> You know how we do it today? Just like that.
>
>
> On Tue, Jun 3, 2014 at 4:20 PM, Michal Mocny wrote:
>
>> Brian/Tommy, may you please write out the complete set of CLI commands
>> you envision for:
>> (a)
You know how we do it today? Just like that.
On Tue, Jun 3, 2014 at 4:20 PM, Michal Mocny wrote:
> Brian/Tommy, may you please write out the complete set of CLI commands you
> envision for:
> (a) create a new project and add 2 platforms
> (b) upgrade an existing project to a specific version
>
Brian/Tommy, may you please write out the complete set of CLI commands you
envision for:
(a) create a new project and add 2 platforms
(b) upgrade an existing project to a specific version
I worry the current package.json proposal is more complex than we realize.
-Michal
On Tue, Jun 3, 2014 at 7
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, 2
+1
On 4 June 2014 at 9:17:09, Brian LeRoux (b...@brian.io) wrote:
…and use package.json to achieve a frictionless env swap on a per project
basis, eventually making the CLI a thin shell that calls into node_modules
ala Grunt, Gulp, etc.
On Tue, Jun 3, 2014 at 4:07 PM, tommy-carlos william
…and use package.json to achieve a frictionless env swap on a per project
basis, eventually making the CLI a thin shell that calls into node_modules
ala Grunt, Gulp, etc.
On Tue, Jun 3, 2014 at 4:07 PM, tommy-carlos williams
wrote:
> You can’t have version x of a plugin for iOS and version y of
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 t
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.
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
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
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 wrote:
> Thinking it through, if cordova platforms are deps
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
NIH: not invented here
On Tue, Jun 3, 2014 at 10:17 AM, Andrew Grieve wrote:
> On Tue, Jun 3, 2014 at 12:19 PM, Brian LeRoux 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.
>
>
>
On Tue, Jun 3, 2014 at 12:19 PM, Brian LeRoux 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
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.
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
platf
On Tue, Jun 3, 2014 at 11:34 AM, Brian LeRoux 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
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 semantic
On Mon, Jun 2, 2014 at 10:14 PM, Andrew Grieve 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 ad
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
Eventually, yes. (Sort of how Grunt works now.)
On Mon, Jun 2, 2014 at 5:52 PM, Terence M. Bandoian
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 j
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
The benefit for the cli is clearly defined deps and removing all the logic
for managing them.
On Mon, Jun 2, 2014 at 4: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 reall
>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 cordo
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
Not sure what your question is.
On Mon, Jun 2, 2014 at 2:03 PM, Brian LeRoux wrote:
> *ahem
>
>
> On Wed, May 28, 2014 at 11:20 AM, Brian LeRoux wrote:
>
> > npm i cordova-ios@3.5.0
> >
> > Right?
> > On May 27, 2014 11:06 PM, "Andrew Grieve" wrote:
> >
> >> Lazy loading is what will give us
*ahem
On Wed, May 28, 2014 at 11:20 AM, Brian LeRoux wrote:
> npm i cordova-ios@3.5.0
>
> Right?
> On May 27, 2014 11:06 PM, "Andrew Grieve" wrote:
>
>> Lazy loading is what will give us the ability to support multiple versions
>> of platforms.
>>
>> If we don't support users choosing the vers
npm i cordova-ios@3.5.0
Right?
On May 27, 2014 11:06 PM, "Andrew Grieve" 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 versio
Also, to Jesse's suggestion about having a package.json for each installed
platform in a cordova project -- I'm not sure that is necessary. You can
require these node scripts explicitly already:
aka: require('./platforms/android/cordova/run') instead of
exec('./platforms/android/cordova/run').
W
I tend to agree with Andrew that it should not be necessary to add
platforms to CLI's package.json dependency list. I'm not sure that there
is a benefit to doing that, except perhaps that ability to add platforms
when offline and you haven't loaded them previously.
On the other hand, I think user
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 ver
I agree with `create` as it applies to the entire platform.
However, the project level scripts are potentially more volatile.
Shouldn't each project have a package.json which exports?
my-project
|-platforms
|-ios
|-package.json
module.exports = { run:Function, build:Function,
clean:Functio
+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\n
+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.ler...@gmail.com [mailto:brian.ler...@gmail.co
73 matches
Mail list logo
