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.
g 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
; >> On Mon, Jun 2, 2014 at 3:42 PM, Ian Clelland <
> > > > > > > > iclell...@chromium.org>
> > > > > > > > > > >> wrote:
> > > > > > > > > > >>
> > > > > > > > > > >> There seems
s directly on NPM. That's why each one
> > > would
> > > > > > > require
> > > > > > > > a
> > > > > > > > > >>> package.json. (which would probably end up in
> > > > > > > > >
n NPM project, we then would have the opportunity
> > (though
> > > > not
> > > > > > the
> > > > > > > > >>> obligation) to make all of the supporting scripts for
> each
> > > > > platform
> >
the command line.
> > > > > > > >>>
> > > > > > > >>> It's not about making platforms into CLI dependencies (any
> > more
> > > > > than
> > > > > > > >>> plugins are CLI dependencies
gt;>> separately, and scriptable without having to spawn subshells.
> > > > > > >>>
> > > > > > >>> And if I have it completely wrong, then let me know -- I'll
> > just
> > > go
> > > > > &
gt; >>>>
> > > > > >>>>
> > > > > >>>> On Mon, Jun 2, 2014 at 2:03 PM, Brian LeRoux
> > wrote:
> > > > > >>>>
> > > > > >>>> *ahem
> > > > > >>>&g
> > wrote:
> > > > >>>>>
> > > > >>>>> npm i cordova-ios@3.5.0
> > > > >>>>>>
> > > > >>>>>> Right?
> > > > >>>>>> On May 27, 2014 11:06 PM, "Andrew Grieve
gt;>
> > > >>>>>> versions
> > > >>>>>
> > > >>>>>> of platforms.
> > > >>>>>>>
> > > >>>>>>> If we don't support users choosing th
version of the platform
> they
> > >>>>>>>
> > >>>>>> want,
> > >>>>>
> > >>>>>> then they will resist updating their version of CLI (like they do
> > >>>>>>>
> >
>> now).
> >>>>>>>
> >>>>>>> I'm very keen to allow users to chose their platform versions, just
> >>>>>>>
> >>>>>> as
> >>>
> >>>> they
> >>>>>>> are able to choo
>>>>>>>
>>>>>>>
>>>>>>> On Tue, May 27, 2014 at 5:57 PM, Mark Koudritsky >>>>>> wrote:
>>>>>>>
>>>>>>> +1
>>>>>>>>
>>>>>>>> Steve
-Original Message-
From: brian.ler...@gmail.com [mailto:brian.ler...@gmail.com] On
Behalf
Of
Brian LeRoux
Sent: Tuesday, May 27, 2014 2:20 PM
To: dev@cordova.apache.org
Subject: adding platforms to npm for dependency sanity
We've discussed this but I'm not sure the whole idea has
> 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\ne
gt; > >> > 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
e
> it
> > >> since
> > >> > npm does its own caching.
> > >> >
> > >> >
> > >> >
> > >> > On Tue, May 27, 2014 at 5:42 PM, Parashuram Narasimhan (MS OPEN
> TECH)
> > <
> > >> > panar...
t; panar...@microsoft.com> wrote:
> >> >
> >> > > +1. This will also be a step towards releasing platforms
> >> independently.
> >> > > Will the CLI have a semver like dependency on the platform specified
> >> > > somewhere ? Woul
..@microsoft.com> wrote:
>> >
>> > > +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') a
ewhere ? Would the cli have to require('npm') and do the install?
> > >
> > > -----Original Message-
> > > From: brian.ler...@gmail.com [mailto:brian.ler...@gmail.com] On Behalf
> > Of
> > > Brian LeRoux
> > > Sent: Tuesday, May 27, 2014 2:20
gt; >
>> >
>> >
>> > 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.
&g
#x27;) and do the install?
> > >
> > > -Original Message-
> > > From: brian.ler...@gmail.com [mailto:brian.ler...@gmail.com] On Behalf
> > Of
> > > Brian LeRoux
> > > Sent: Tuesday, May 27, 2014 2:20 PM
> > > To: dev@cordova.apache.org
> >
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.com] On Behalf
> Of
> > Brian LeRoux
> > Sent: Tuesday, May 27, 2014
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
an LeRoux
> Sent: Tuesday, May 27, 2014 2:20 PM
> To: dev@cordova.apache.org
> Subject: adding platforms to npm for dependency sanity
>
> We've discussed this but I'm not sure the whole idea has crystalized. My
> proposal (based on previous discussions) below. I&#
:brian.ler...@gmail.com] On Behalf Of Brian
LeRoux
Sent: Tuesday, May 27, 2014 2:20 PM
To: dev@cordova.apache.org
Subject: adding platforms to npm for dependency sanity
We've discussed this but I'm not sure the whole idea has crystalized. My
proposal (based on previous discussions) below. I'
We've discussed this but I'm not sure the whole idea has crystalized. My
proposal (based on previous discussions) below. I'll use iOS as an example
but this applies to all platforms supported by the CLI.
First, we'd add two files:
cordova-ios
|-package.json
'-index.js
…I don't think I need to de
74 matches
Mail list logo
