Re: [DISCUSS] non-global Cordova installs

[Oliver Salzburg]

Our DX is not good and this proposal would have the potential to have a
positive impact on that. I'm sorry that you're not convinced yet.

Because I don't want to skip back and forth between GitHub and the
mailing list, I'll address your points here.

- When you start a new project, unless you create a new cordova project
every week, you'll download cordova. npx will only help you in
downloading the package and if you have downloaded it in the past, it
will be pulled from the cache.

- Yes, the Cordova CLI behavior can change over time, which is exactly
why you would not want to share a single global version with all of your
projects. I consider this a pro-local point.

- It is 4 more characters to type. Yes. I give you that. But if you want
to interact with a local installation of cordova, what exactly is the
alternative? Not installing locally? I disagree.

- Your suggestion regarding writing a completely new module to initiate
a cordova project is completely besides the point here. If you had that
module, you'd still want to use it with npx. And using `npx cordova`
pulls cordova into the cache where you are going to want to have it
anyway. If you had a slimmed down module, you now still need to download
cordova.

By using npx, given your usage examples, you would have less downloads
instead of more.

I'm sorry, Brody, I don't see your points and I don't feel like they
have been weighed appropriately against the benefits I proposed earlier.

I would also appreciate it if we could try to keep the conversation to a
single media. The split between mailing list and GitHub is not constructive.

Almost like putting part of your application in a global context and
another part in a local context is not constructive...

On 2019-05-10 23:08, Chris Brody wrote:
> I am very sorry to say that I am still not convinced about this idea.
> I just raised some concerns in a recent comment in:
> https://github.com/apache/cordova-docs/issues/838
> 
> And I think I am not the only one right now.
> 
> As I said in cordova-docs#838, I would favor that we mention using
> `npx cordova` *as an option* in a limited number of places.
> 
> I would like to express my appreciation to Oliver for the time and
> effort has given to improve the documentation, and to contribute a
> number of updates and fixes in the past. But I would rather take the
> extra time and effort to ensure we keep up the best app DX we can.
> 
> And I don't really follow what you mean about CORDOVA_CMDLINE, would
> probably be easiest if we keep it in a separate discussion thread or
> issue.
> 
> On Fri, May 10, 2019 at 3:05 PM Oliver Salzburg
>  wrote:
>>
>> I have already started working on a PR to make the necessary changes to
>> the documentation, as I was under the impression that consensus
>> regarding this issue was already reached:
>>
>> https://github.com/apache/cordova-docs/pull/987
>>
>> Specifically this might be of interest:
>>
>> https://github.com/apache/cordova-docs/blob/04363c2796199f5379fa2b5f99ac8b1a488a/www/docs/en/dev/guide/cli/index.md
>>
>> I believe installing the cordova dependency as a devDependency should be
>> part of the "create" task. I was planning to propose the necessary
>> changes in another PR, but the freshly ignited debate caused me to hold
>> on that.
>>
>> I also brought up another area of concern regarding CORDOVA_CMDLINE in
>> hooks. I mentioned this in the PR.
>>
>>
>> On 2019-05-10 20:42, Jesse wrote:
>>> Also thanks for the comprehensive write-up Oliver!
>>>
>>> Yeah, I am good with a move to recommend npx.
>>> I just ran thru the steps and everything seems to work fine with it.
>>>
>>> One other reservation I had was just about network usage, and being
>>> sensitive to places where bandwidth during the day is extremely costly.  I
>>> verified that having previously installed platforms android+ios in other
>>> projects, I was able to `npx cordova platform add android` with the network
>>> off and it used a cached version.
>>>
>>> Are our new getting started steps going to be this ?:
>>> ```
>>> npx cordova create myNewCordovaApp
>>> cd myNewCordovaApp
>>> npm i cordova --save-dev
>>> npx cordova platform add android
>>> npx cordova run android
>>> ```
>>>
>>> I believe we may also find some issues around cordova-lib having
>>> expectations of number of args and how it outputs some error messages, but
>>> hopefully tests will reveal those.
>>>
>>> Cheers,
>>>   Jesse
>>>
>>>
>>> On Fri, May 10, 2019 at 2:46 AM  wrote:
>>>
>>>> Thanks for that

Re: [DISCUSS] non-global Cordova installs

[Oliver Salzburg]

I have already started working on a PR to make the necessary changes to
the documentation, as I was under the impression that consensus
regarding this issue was already reached:

https://github.com/apache/cordova-docs/pull/987

Specifically this might be of interest:

https://github.com/apache/cordova-docs/blob/04363c2796199f5379fa2b5f99ac8b1a488a/www/docs/en/dev/guide/cli/index.md

I believe installing the cordova dependency as a devDependency should be
part of the "create" task. I was planning to propose the necessary
changes in another PR, but the freshly ignited debate caused me to hold
on that.

I also brought up another area of concern regarding CORDOVA_CMDLINE in
hooks. I mentioned this in the PR.


On 2019-05-10 20:42, Jesse wrote:
> Also thanks for the comprehensive write-up Oliver!
> 
> Yeah, I am good with a move to recommend npx.
> I just ran thru the steps and everything seems to work fine with it.
> 
> One other reservation I had was just about network usage, and being
> sensitive to places where bandwidth during the day is extremely costly.  I
> verified that having previously installed platforms android+ios in other
> projects, I was able to `npx cordova platform add android` with the network
> off and it used a cached version.
> 
> Are our new getting started steps going to be this ?:
> ```
> npx cordova create myNewCordovaApp
> cd myNewCordovaApp
> npm i cordova --save-dev
> npx cordova platform add android
> npx cordova run android
> ```
> 
> I believe we may also find some issues around cordova-lib having
> expectations of number of args and how it outputs some error messages, but
> hopefully tests will reveal those.
> 
> Cheers,
>   Jesse
> 
> 
> On Fri, May 10, 2019 at 2:46 AM  wrote:
> 
>> Thanks for that structured write-up, Oliver. You saved me from writing all
>> of that myself.
>>
>> +100 on all those points
>>
>> Oliver Salzburg  schrieb am Fr., 10. Mai 2019,
>> 11:01:
>>
>>> I don't see how third-party tools like nvm or nvm-windows play a role in
>>> this. If those tools have defects, so be it, but that shouldn't steer a
>>> decision when the tools in question ship with the official tools that we
>>> use (NodeJS).
>>> This holds especially true if the issues have already been fixed.
>>>
>>> That being said, it seems like part of this discussion is already going
>>> into a direction of local vs. global Cordova install, which I didn't
>>> even think was up for debate anymore. What was up for debate last night,
>>> was how to interact with local Cordova installs.
>>>
>>> However, let me reiterate all points regarding the entire issue:
>>>
>>> 1. A global Cordova installation is a huge issue in itself, as
>>> components in Cordova interact with each other in a way that sometimes
>>> the global components are used and sometimes the local components. This
>>> happens during runs of individual tasks, like "prepare", where both the
>>> local and the global cordova-common are loaded for example.
>>> This issue would easily be avoided by placing Cordova itself locally in
>>> the project. It allows a per-project Cordova version, which is
>>> controlled through the package.json, like any other Cordova component.
>>> Having your core component global is a horrible design and many other
>>> projects have already realized this years ago and adjusted accordingly.
>>> Think gulp-cli, babel-cli, ...
>>>
>>> The current approach leads to extremely hard to debug issues and,
>>> ultimately, developer frustration.
>>>
>>> 2. Interacting with a local dependency that has a binary entrypoint in
>>> node_modules/.bin is exactly what npx was made for. It is already
>>> established as a tool in the NodeJS world and many other projects make
>>> use of it in the manner we're suggesting.
>>> https://reactjs.org/docs/create-a-new-react-app.html
>>> https://babeljs.io/docs/en/babel-cli
>>> https://gulpjs.com/docs/en/getting-started/quick-start
>>>
>>> There needs to be a very good reason to avoid adapting a well
>>> established approach in the environment you're working in. I'll get to
>>> that.
>>>
>>> 3. Suggesting npx as a way to interact with the Cordova CLI not only
>>> serves the purpose of invoking the node_module/.bin entrypoint, but it
>>> will also already work to create a new project when cordova isn't even
>>> installed. This reduces the barrier of entry and establishes a way to
>>> interact with Cordova that will always work.
&

Re: [DISCUSS] non-global Cordova installs

[Oliver Salzburg]

I don't see how third-party tools like nvm or nvm-windows play a role in 
this. If those tools have defects, so be it, but that shouldn't steer a 
decision when the tools in question ship with the official tools that we 
use (NodeJS).

This holds especially true if the issues have already been fixed.

That being said, it seems like part of this discussion is already going 
into a direction of local vs. global Cordova install, which I didn't 
even think was up for debate anymore. What was up for debate last night, 
was how to interact with local Cordova installs.


However, let me reiterate all points regarding the entire issue:

1. A global Cordova installation is a huge issue in itself, as 
components in Cordova interact with each other in a way that sometimes 
the global components are used and sometimes the local components. This 
happens during runs of individual tasks, like "prepare", where both the 
local and the global cordova-common are loaded for example.
This issue would easily be avoided by placing Cordova itself locally in 
the project. It allows a per-project Cordova version, which is 
controlled through the package.json, like any other Cordova component.
Having your core component global is a horrible design and many other 
projects have already realized this years ago and adjusted accordingly. 
Think gulp-cli, babel-cli, ...


The current approach leads to extremely hard to debug issues and, 
ultimately, developer frustration.


2. Interacting with a local dependency that has a binary entrypoint in 
node_modules/.bin is exactly what npx was made for. It is already 
established as a tool in the NodeJS world and many other projects make 
use of it in the manner we're suggesting.

https://reactjs.org/docs/create-a-new-react-app.html
https://babeljs.io/docs/en/babel-cli
https://gulpjs.com/docs/en/getting-started/quick-start

There needs to be a very good reason to avoid adapting a well 
established approach in the environment you're working in. I'll get to that.


3. Suggesting npx as a way to interact with the Cordova CLI not only 
serves the purpose of invoking the node_module/.bin entrypoint, but it 
will also already work to create a new project when cordova isn't even 
installed. This reduces the barrier of entry and establishes a way to 
interact with Cordova that will always work.


It is extremely convenient and developers want convenience. If there is 
one thing we don't need in Cordova, then it is to overcomplicate things, 
frustrate developers and drive them away.


4. That being said, convenience comes at a price and Dmitry has outlined 
the issues that come with npx very well last night on Slack. I agree 
with his points and they are also my own, but I feel the benefits 
massively outweigh these risks.


npx downloads packages that aren't available locally and executes them. 
This is by-design and a feature I mentioned earlier. It also opens the 
door for a myriad of security issues, as it has the potential to run 
unwanted code with every single execution of `npx cordova`.
You just have to type `npx cordoa` once, and suddenly you get a 
typosquatted package from someone that sends off local data to the 
cloud. As a matter of fact, I published the package "rebecca" years ago 
to illustrate exactly this point. Try `npx rebecca` to see what I mean.
While you can run npx with --no-install to avoid this, this would ruin 
any convenience we're trying to establish here.


npx also adds another layer of complexity. You need an additional Node 
process to even locate the entrypoint you want to invoke, check if 
downloads need to be made and so on. This would happen every single time 
you invoke the Cordova CLI. I consider this a minor issue, but it is an 
issue nonetheless.



With those points in mind, nobody is forced to use Cordova in the way we 
suggest in the docs. I can already install Cordova locally and use it 
with npx if I want to. Users who prefer a global installation of Cordova 
to avoid the above mentioned issues, are still free to do so and they 
should find instructions on how to set that up in the documentation.


This is about suggesting to users a way to get started with Cordova with 
as little friction as possible and npx achieves this extremely well and 
leaves us with a far better project structure by default.


On 10/05/2019 10:06, Jan Piotrowski wrote:

While that is correct, nvm-windows indeed had problems with npx not
working after it was first added to node - so Julio's was indeed true
in the past.
Luckily it was fixed, so even we lowly Windows users now can use npx.

Am Fr., 10. Mai 2019 um 09:48 Uhr schrieb Oliver Salzburg
:

npx ships with Node.

On Fri, May 10, 2019, 00:33 Jesse  wrote:


Hello Dmitry,

In my mind, cordova-cli is intended to be installed globally, in situations
where that is not is possible we could *maybe* recommend that users use
npx, but I don't think it's a great experience.  btw, npx needs to be
globally

Re: [DISCUSS] non-global Cordova installs

[Oliver Salzburg]

npx ships with Node.

On Fri, May 10, 2019, 00:33 Jesse  wrote:

> Hello Dmitry,
>
> In my mind, cordova-cli is intended to be installed globally, in situations
> where that is not is possible we could *maybe* recommend that users use
> npx, but I don't think it's a great experience.  btw, npx needs to be
> globally installed ... so ok!?
> This is really just a symptom of a bad node setup, and would never happen
> if using nvm or similar node switcher.
>
> The issue raised in that thread appears to be simply related to where
> config stores its data, specifically opt in/out of telemetry.
>
>
>
>
> On Thu, May 9, 2019 at 2:45 PM Dmitry Blotsky 
> wrote:
>
> > Hi all,
> >
> > It’s been a while. :) I hope you’re all doing well.
> >
> > I’m writing to start some mailing list discussion about this GitHub
> issue:
> > https://github.com/apache/cordova-docs/issues/838.
> >
> > Please say if we should continue talking there, and we can do that
> instead.
> >
> > If not, let’s continue here.
> >
> > It sounds like we’ve got a request to run Cordova without a global sudo
> > install. What are the ways you all can think of to achieve this?
> >
> > Dmitry
>

Re: [DISCUSS] Cordova Lib 9.0.0 Release

[Oliver Salzburg]

I never marked it as such and the tests only passed a couple moments ago.

Excuse the unreasonable delays!

On 15/03/2019 14:24, Jan Piotrowski wrote:

The PR is marked as Work in Progress. If you want it to get reviewed
and merged you should remove that.

Am Fr., 15. März 2019 um 13:18 Uhr schrieb Oliver Salzburg
:

I really think we should get #680[1] merged before the release.

It should be good in a moment.

[1]: https://github.com/apache/cordova-lib/pull/680

On 14/03/2019 07:31, Bryan Ellis wrote:

Does anyone have any reason to delay the Cordova Lib release?
Any outstanding patches to land?

If not, I will start the release tomorrow.

The versions to be released are:
cordova-lib@9.0.0


-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DISCUSS] Cordova Lib 9.0.0 Release

[Oliver Salzburg]

I really think we should get #680[1] merged before the release.

It should be good in a moment.

[1]: https://github.com/apache/cordova-lib/pull/680

On 14/03/2019 07:31, Bryan Ellis wrote:

Does anyone have any reason to delay the Cordova Lib release?
Any outstanding patches to land?

If not, I will start the release tomorrow.

The versions to be released are:
cordova-lib@9.0.0



-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [Proposal] Supporting Proper DATA_URL for Camera plugin

[Oliver Salzburg]

What is the downside of just introducing new options and not creating a 
breaking change?
And what is the positive impact of this change that it necessitates that 
every consumer of the existing API change their code?


IMHO that has not been made clear enough.

On 01/03/2019 02:17, Hazem Saleh wrote:

  My only reservation is that it is a questionable api imho, converting

binary to text just to pass it through the bridge is computationally
expensive and ram intensive and better cameras continue to make it worse.

Regarding this, I think we can generally recommend in the documentation to
use the base64 API option in case of small images (and it is up to the app
developers to decide based on the problem that they are trying to solve).

What do you think?

On Wed, Feb 27, 2019 at 5:17 AM Jesse  wrote:


I think I am okay with the breaking change, as long as we update major
My only reservation is that it is a questionable api imho, converting
binary to text just to pass it through the bridge is computationally
expensive and ram intensive and better cameras continue to make it worse.


On Feb 27, 2019, at 1:37 AM, julio cesar sanchez 

wrote:

I’m +1 to changing it and doing a major release.

It was called data url but it’s not a data url, that’s a bug that has
become “feature”.
I think we should have the new type but that returns current string and
make data url return the real data url and document it on the breaking
changes.


El miércoles, 27 de febrero de 2019, Oliver Salzburg <
oliver.salzb...@gmail.com> escribió:


I don't think the behavior should be changed. If anything, just

introduce

another type that has the prefix. And maybe add an alias for the

existing

type to make the differences clearer.


On 27/02/2019 03:51, Hazem Saleh wrote:

Hello Team,

When calling navigator.camera.getPicture with destinationType set to
Camera.DestinationType.DATA_URL, the success function is called with

the

base64 encoded data while it should has suitable data URL format on the
following form:

data:[][;base64],


It is an old issue in the library and it was previously reported under:
https://issues.apache.org/jira/browse/CB-9819

And recently, it was also reported by one of the library users:
https://github.com/apache/cordova-plugin-camera/issues/420

I have a solution for this problem in Android[1], and I can create a
similar one for iOS and windows platform but my question is, Do we

really

want to support this since it is a breaking change as in all older
versions
of Cordova, a base64 encoded data was always sent, and definitely all
documentation is needed to be updated.

[OT] I'm sending this email since Julio asked me to post this proposal
here
in a GitHub issue discussion.

Thanks

[1]
https://github.com/hazems/cordova-plugin-camera/commit/e6609
c0b6a590a30ef7802826888693142576bee



-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [Proposal] Supporting Proper DATA_URL for Camera plugin

[Oliver Salzburg]

I don't think the behavior should be changed. If anything, just 
introduce another type that has the prefix. And maybe add an alias for 
the existing type to make the differences clearer.


On 27/02/2019 03:51, Hazem Saleh wrote:

Hello Team,

When calling navigator.camera.getPicture with destinationType set to
Camera.DestinationType.DATA_URL, the success function is called with the
base64 encoded data while it should has suitable data URL format on the
following form:

data:[][;base64],


It is an old issue in the library and it was previously reported under:
https://issues.apache.org/jira/browse/CB-9819

And recently, it was also reported by one of the library users:
https://github.com/apache/cordova-plugin-camera/issues/420

I have a solution for this problem in Android[1], and I can create a
similar one for iOS and windows platform but my question is, Do we really
want to support this since it is a breaking change as in all older versions
of Cordova, a base64 encoded data was always sent, and definitely all
documentation is needed to be updated.

[OT] I'm sending this email since Julio asked me to post this proposal here
in a GitHub issue discussion.

Thanks

[1]
https://github.com/hazems/cordova-plugin-camera/commit/e6609c0b6a590a30ef7802826888693142576bee



-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [dev] some bad press

[Oliver Salzburg]

Why do you feel the need to be competitive? Isn't it enough to serve all 
the existing users that appreciate the framework as it is?


Seems fine to me. And popularity is a pretty bad quality indicator IMHO, 
especially when the source is the SO community.


On 2019-01-24 19:31, Chris Brody wrote:

I recently saw an article about app frameworks, where Cordova sadly
shows up as the most dreaded framework in an image near the end:
https://medium.com/zerotomastery/tech-trends-showdown-react-vs-angular-vs-vue-61ffaf1d8706

and I just raised a minor usability issue:
https://github.com/apache/cordova/issues/71

And this is just the tip of the iceberg.

It makes me pretty sad to see this kind of bad press despite the
amount of efforts taken over the years to update and maintain such a
widely used framework.

I am starting to wonder if it is worth the amount of effort needed for
Cordova to remain competitive with alternatives such as Capacitor and
React Native.

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DISCUSS] Tools Release for Cordova 9

[Oliver Salzburg]

Are we getting cordova-serve#14 into this release?

https://github.com/apache/cordova-serve/pull/14

On 2018-12-18 08:35, Bryan Ellis wrote:

Does anyone have any reason to delay tools release?
Any outstanding patches to land?

I believe everything planned for the next major had been merged,
and would like to continue stage 2 of the Cordova 9 release process[1].

If not, I will start the release tomorrow.

The versions to be released are:
cordova-fetch@2.0.0
cordova-serve@3.0.0
cordova-app-hello-world@4.0.0

[1] https://github.com/apache/cordova/issues/10



-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Nomination for a new chair for Apache Cordova

[Oliver Salzburg]

+1

Thanks for everything!

On Fri, Dec 7, 2018 at 10:22 AM Jan Piotrowski  wrote:

> +1
>
> Thanks to you both!
> Am Fr., 7. Dez. 2018 um 10:05 Uhr schrieb julio cesar sanchez
> :
> >
> > +1
> >
> > And thanks to you for all this years and to him for taking over
> >
> > El El vie, 7 dic 2018 a las 8:02, Toplak Daniel 
> > escribió:
> >
> > > Hello Shazron,
> > >
> > > thank you for your hard work the last few years and I will totally
> agree
> > > with the nomination of Jesse :-)
> > > +1
> > >
> > > Grüße / Regards
> > > Daniel Toplak
> > > Head of Mobile Development
> > >
> > > > -Ursprüngliche Nachricht-
> > > > Von: Shazron 
> > > > Gesendet: Friday, December 7, 2018 03:30
> > > > An: dev@cordova.apache.org
> > > > Betreff: Nomination for a new chair for Apache Cordova
> > > >
> > > > Hello beloved Community!
> > > > I have been the chair of Apache Cordova since around April 2014 (~4.5
> > > years).
> > > >
> > > > The duties are mostly administrative: board reports, PMC management
> etc.
> > > Some
> > > > of it is listed here in the README:
> > > > https://github.com/apache/cordova-apache-board-reports
> > > >
> > > > I think it is time for new leadership. I have decided to resign my
> > > duties as the
> > > > Apache Cordova chair, hopefully for the upcoming new year of 2019.
> > > >
> > > > I nominate Jesse MacFadyen as the next chair. Jesse has been with me
> at
> > > the start
> > > > when Cordova was PhoneGap. Although we didn't give birth to it, we
> > > helped work
> > > > on improving Cordova from being an infant to adulthood (together with
> > > our great
> > > > team), particularly on cordova-ios.
> > > > 10 years is adulthood in software!
> > > >
> > > > He has also contributed greatly to the other platforms and tooling,
> > > particularly
> > > > cordova-windows. He has the most experience with helping run the
> Cordova
> > > > project out of the remaining active contributors.
> > > >
> > > > As an Apache Member (https://www.apache.org/foundation/members.html)
> > > > he also understands and helps uphold 'The Apache Way'
> > > > (https://www.apache.org/foundation/how-it-works.html) and will be a
> > > great liaison
> > > > with the Board.
> > > >
> > > > I'm not going anywhere and I will still contribute to the project in
> my
> > > areas of
> > > > expertise.
> > > >
> > > > Thank you.
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > >
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: [dev] Introduce ES6 classes or not?

[Oliver Salzburg]

I'm in favor of ES6 classes.

But that doesn't mean that everything that _can_ be written with classes 
should. Pick the right tool for the job.


While you can achieve the same object structure by just extending the 
prototype, classes have the benefit of keeping related code parts close 
to each other. A class is usually defined in a single `class {}` block. 
With prototype extensions that is not required and it can be a lot 
harder to determine how an object is constructed.


So, as a language feature, they might not provide any benefits, but from 
a code point of view, I think there are several. I'd put some of that 
syntactic sugar in my tea.


On 2018-11-30 03:20, Chris Brody wrote:

I was wondering what our sentiment should be about using ES6 classes?

My own opinion in coming in a response email.

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DISCUSS] cordova-android@7.1.3 patch release, any objections?

[Oliver Salzburg]

Maybe it's time to get rid of the warning? It was confusing me as well when
I first saw it and that was already quite some time ago.

On Tue, Nov 20, 2018 at 6:38 PM gandhi rajan 
wrote:

> Ya Jesse. While creating hello world app as mentioned in
>
> https://github.com/apache/cordova-coho/blob/master/docs/platforms-release-process.md#2-hello-world-app-with-cordova-cli
> I got the error regarding plugin installation but android platform addition
> was successful. As you said its not a blocker. But unfortunately I m not
> able to provide the details Julio asked for as the setup is in my office
> desktop. Will get back with more details on this.
>
> On Tue, Nov 20, 2018 at 11:01 PM Jesse  wrote:
>
> > There is a reported error in the output, the android template app
> includes
> > the whitelist plugin, but the plugin itself only supports older versions
> of
> > Cordova-android.
> >
> > The message is something like ‘failed to install plugin ... moving on’.
> > Ultimately not an issue other than the appearance that something has gone
> > wrong. Not a blocker, imho.
> >
> > > On Nov 20, 2018, at 9:13 AM, gandhi rajan 
> > wrote:
> > >
> > > Hi Julio,
> > >
> > > Thanks for the response. Will have a check on this tomorrow and get
> back
> > to
> > > you on this.
> > >
> > > On Tue, Nov 20, 2018 at 10:41 PM julio cesar sanchez <
> > jcesarmob...@gmail.com>
> > > wrote:
> > >
> > >> What's your CLI version?
> > >> What error did you get?
> > >> node and npm versions?
> > >>
> > >> It's installing fine on my computer
> > >>
> > >> El mar., 20 nov. 2018 a las 17:51, gandhi rajan (<
> > gandhiraja...@gmail.com
> > >>> )
> > >> escribió:
> > >>
> > >>> Hi All,
> > >>>
> > >>> While testing Cordova Android 7.1.3, license check and npm audit
> > passed.
> > >>>
> > >>> But while executing "cordova platform add
> > >>> https://github.com/apache/cordova-android#7.1.3 " , android platform
> > >> added
> > >>> successfully but whitelist plugin dint got added and failed with
> error.
> > >> Am
> > >>> I missing something?
> > >>>
> > >>> cordova platform add https://github.com/apache/cordova-android#7.1.3
> > >>>
> > >>> On Mon, Nov 19, 2018 at 9:33 PM julio cesar sanchez <
> > >>> jcesarmob...@gmail.com>
> > >>> wrote:
> > >>>
> >  +1, ship it
> > 
> >  El dom., 18 nov. 2018 a las 1:51, Chris Brody (<
> chris.br...@gmail.com
> > >>> )
> >  escribió:
> > 
> > > Does anyone have any reason to delay a cordova-_android_ platform
> >  release?
> > >
> > > Any outstanding patches to land?
> > >
> > > If not, I will start the release tomorrow.
> > >
> > >
> -
> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > >
> > >
> > 
> > >>>
> > >>>
> > >>> --
> > >>> Regards,
> > >>> Gandhi
> > >>>
> > >>> "The best way to find urself is to lose urself in the service of
> others
> > >>> !!!"
> > >>>
> > >>
> > >
> > >
> > > --
> > > Regards,
> > > Gandhi
> > >
> > > "The best way to find urself is to lose urself in the service of others
> > !!!"
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
> >
>
> --
> Regards,
> Gandhi
>
> "The best way to find urself is to lose urself in the service of others
> !!!"
>

Re: App Store rejection (Cordova IOS APP)

[Oliver Salzburg]

Can't confirm. Our app is going through just fine.

On Mon, Oct 29, 2018, 03:38 Stephen Day  wrote:

> Hi All,
>
> I received the following app-store review rejection for an angular 6 app
> wrapped in the Cordova framework with a splash screen:
>
>
>
> It appears Apple are rejecting Cordova apps in their app stores. Would you
> be able to advise if there is anything I can do on the corodva/angular side
> to get it to pass this review?
>
> Thanks
> Steve
>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [cordova-tizen] support cordova-tizen

[Oliver Salzburg]

Hi Piotr,

some of the more seasoned contributors can probably be of more help, but 
I would recommend joining the Cordova Slack http://slack.cordova.io/ for 
faster information exchange.


I recommend the #dev channel ;)

Cheers,
Oliver


On 2018-10-19 15:11, Piotr Kosko wrote:


Hello,

I am Tizen Web API developer in Samsung R Poland. Currently we are 
thinking about fully supporting Tizen as a platform in Cordova. I know 
that currently cordova-tizen project exists, but it needs an update to 
work. I am thinking about what to start with about supporting Tizen 
platform.


First I created an issue in cordova-lib 
https://github.com/apache/cordova-lib/issues/715, but after the 
suggestion there, I think the discussion could be continued here.


During my own research I noticed that some packages need to co-work to 
make the 'tizen' a supported platform in cordova CLI. Needed changes are:


  * just configuration update to add 'tizen':
  o cordova-lib
  o cordova-serve
  * more complex changes to support all operations
  o cordova-tizen

I am afraid that I am totally new about the contributing into cordova 
so I need your suggestion what to start with about modifying the 
cordova-tizen module and how to verify my changes. I've read about 
nightly builds and other stuff but as my change will not be visible 
without modification of all above packages I am not sure how to start. 
I hope that you could share your thoughts and help me to go into the 
right direction.


Best regards,
Piotr Kosko

--


Piotr Kosko
Samsung R Insitute Poland
Samsung Electronics
p.ko...@samsung.com 

Re: plugins release?

[Oliver Salzburg]

I believe the issue with the pending releases is not that nobody is 
performing the release task. There are still implementation details 
being worked on if I'm not mistaken.


The next release will supposedly introduce several major breaking 
changes, which have to be prepared for thoroughly.


On 2018-10-13 22:02, julio cesar sanchez wrote:

Today I was checking github issues and noticed that a lot of them were
supposedly fixed already, but people are reporting them again as we have
not done a release since April and they are using the latest release and
not master.

So, is anybody willing to do a release? If not I can try, but last time I
tried I wasn't able to finish it because of some problem with coho.

Also, related to coho, it supposedly creates a JIRA issue, but that's not
possible anymore, so should we manually create a release issue per plugin?
Or patch coho to automatically create them? (if possible).
How are you doing it since we switched to github issues? (cc Chris as I
think you did most/all releases since then)




-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [VOTE] cordova-cli@8.1.2 patch release

[Oliver Salzburg]

I vote +1

- Confirmed sigs & hashes with `coho verify-archive` [1]
- Verified sha1s match tags with `coho verify-tags`
- Checked out the branch and ran `npm test`
- Continuous build was green when repo was tagged

[1] The signature is a match, but I have not verified the signature yet.

On 2018-10-05 21:15, Chris Brody wrote:
> Please review and vote on this cordova-cli@8.1.2 tools patch release
> by replying to this email (and keep discussion on the DISCUSS thread)
> 
> Release issue: https://github.com/apache/cordova-lib/issues/706
> 
> Both tools have been published to dist/dev:
> https://dist.apache.org/repos/dist/dev/cordova/GH-706/cordova-8.1.2.tgz
> 
> The packages were published from their corresponding git tags:
> 
> cordova-cli: 8.1.2 (739108ddc6)
> 
> Upon a successful vote I will upload the archives to dist/, publish
> them to npm, and post the corresponding blog post.
> 
> Voting guidelines:
> https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
> 
> Voting will go on for a minimum of 48 hours.
> 
> I vote +1:
> * Ran coho audit-license-headers over the relevant repos
> * Ran coho check-license to ensure all dependencies and
> subdependencies have Apache-compatible licenses
> * Ensured continuous build was green when repos were tagged
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Commit package-lock.json in next major Cordova release or not?

[Oliver Salzburg]

I would agree with your conclusion. Except that my personal 
interpretation of it was that npm is as stable as a hovercraft filled 
with eels. :D


On 2018-09-17 13:22, Chris Brody wrote:

On Mon, Sep 17, 2018 at 5:35 AM Oliver Salzburg
 wrote:

I would also suggest to have a brief look at the issues other users are
reporting regarding this:

- https://github.com/npm/npm/issues?utf8=%E2%9C%93=is%3Aissue+package-lock
- https://npm.community/search?q=package-lock%20category%3A6

I see that there has been quite a bit of confusion around the package
lock behavior, and maybe some bugs found, in the past. The package
lock behavior seems to have changed over the past few npm releases,
which indicates to me that they would have fixed some bugs as well. Is
there anything else we can conclude from these links?


Of course, in the end, nothing beats a validation against own targets.

Agreed on my part.

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DISCUSS] When to do npm shrinkwrap?

[Oliver Salzburg]

The shrinkwrap *can* be a tool to have more control over the dependency 
tree. But I would consider that a hack. To my understanding the 
shrinkwrap is not meant to be manually edited.


In general, it is just a best practice means to lock down dependency 
versions, without the negative effects of maintaining a lockfile during 
development.


However, shrinkwrapping produces the same possibly erroneous output that 
the lockfile has. So this (for me) is something that absolutely requires 
an isolated environment. Linked modules are detected as being bundled 
dependencies for example. So, contrary to what npm says, this should not 
be committed to VCS either :)


On 2018-09-17 13:14, Chris Brody wrote:

Originated in another thread ([1]), moving into a new thread.

My understanding is that we should only do npm shrinkwrap if needed to
deal with a dependency problem in an end-user package such as
cordova-cli.

I would like to ask people to please use references whenever possible.

[1] 
https://lists.apache.org/thread.html/7f92561d382f143aaf49e083bbe215dcf95a3f4d8b6e3cbb6089a5f3@%3Cdev.cordova.apache.org%3E

On Mon, Sep 17, 2018 at 5:38 AM Oliver Salzburg
 wrote:

+1 to shrinkwrap before publish

On 2018-09-15 00:27, raphine...@gmail.com wrote:

Please note that I'm not suggesting to commit shrinkwrap to the master of
every repository. That is what had been discussed in the mailing list
thread from 2014 that you shared. That option was dismissed then, and
rightly so. It is also strongly advised against in the npm docs.

I suggest using it only in release branches of CLI or other non-library
releases, so they are immutable and don't mutate over time. _This is
exactly the intended use_. And it comes at no cost other than having to run
`npm shrinkwrap` right before the release.

Plus, it allows us to override transitive dependency versions for a release
if absolutely necessary.

Am Sa., 15. Sep. 2018 um 00:16 Uhr schrieb Jesse :


I personally see shrinkwrap as a step in the wrong direction, I feel like
it has been explored in the past, and the general consensus is that it is
something to avoid.
If committing package-lock is contentious, I am okay with skipping it, but
we need to be careful to lock down our own dependencies and not use
wildcards.

We have flexibility in our current GitHub repos, which allow us to remix
and freely link other dependent packages so we can debug right through our
deps.  I agree we need more stability around the release/publish steps so
we can move more quickly through the collection of packages that make up a
'tools' release.

@purplecabbage
risingj.com


On Fri, Sep 14, 2018 at 2:56 PM  wrote:


No. This won't fix anything. Plus it goes directly against npm's
recommendation. Please double check the docs for the use cases of
package-lock.json vs npm-shrinkwrap.json.

Am Fr., 14. Sep. 2018 um 23:48 Uhr schrieb Chris Brody <
chris.br...@gmail.com>:


A really nice alternative may be to turn the generated
package-lock.json into npm-shrinkwrap.json (using npm shrinkwrap
command) then commit npm-shrinkwrap.json. Then I think any other npm
install updates would update npm-shrinkwrap.json instead of
package-lock.json. Could be more predictable and easier to understand.

This was already discussed in 2014 [1], thanks to Jesse for the link in
[2].

Thanks for the suggestion to use npm shrinkwrap as a solution for
cordova-cli 8.1.0 minor release in [2].

[1]


https://lists.apache.org/thread.html/99184622129935eb473e843e583bf6648faff279a014e8508cc2c660@1411013202@%3Cdev.cordova.apache.org%3E

[2]


https://lists.apache.org/thread.html/f89a074add24f2ace7006b0211cf43a47cc5c1a0a65932fc22515828@%3Cdev.cordova.apache.org%3E

On Fri, Sep 14, 2018 at 3:53 PM Chris Brody 

wrote:

To be honest I have pretty limited experience with package lock file
and it is now starting to show. From Oliver's very unfortunate
experience I would conclude that this is something we should do very
carefully and not just on a whim. Some things I can think of:

* always use recent version of npm such as npm@6.4.1 to generate or
update package-lock.json
* do not use. npm cache when generating or updating

package-lock.json,

or use the npm cache with extreme care (also limited experience for
me)
* be extremely careful with assumptions; I think we should both
double-check the documentation and do our own experimentation, like I
did in <https://github.com/apache/cordova-cli/pull/325> to validate

as

best we can
* semver package seems to be a major library package used by npm; we
should both read the documentation and experiment, ideally with its
own test cases

On Fri, Sep 14, 2018 at 9:47 AM Oliver Salzburg
 wrote:

The problems that appear when you have linked dependencies is that

npm

will pick them up as being bundled and mark them as such in the
lockfile. *However* this behavior has changed in the past. At one

point

this affected any direct dependency, at another point it "only"

Re: Commit package-lock.json in next major Cordova release or not?

[Oliver Salzburg]

+1 to shrinkwrap before publish

On 2018-09-15 00:27, raphine...@gmail.com wrote:

Please note that I'm not suggesting to commit shrinkwrap to the master of
every repository. That is what had been discussed in the mailing list
thread from 2014 that you shared. That option was dismissed then, and
rightly so. It is also strongly advised against in the npm docs.

I suggest using it only in release branches of CLI or other non-library
releases, so they are immutable and don't mutate over time. _This is
exactly the intended use_. And it comes at no cost other than having to run
`npm shrinkwrap` right before the release.

Plus, it allows us to override transitive dependency versions for a release
if absolutely necessary.

Am Sa., 15. Sep. 2018 um 00:16 Uhr schrieb Jesse :


I personally see shrinkwrap as a step in the wrong direction, I feel like
it has been explored in the past, and the general consensus is that it is
something to avoid.
If committing package-lock is contentious, I am okay with skipping it, but
we need to be careful to lock down our own dependencies and not use
wildcards.

We have flexibility in our current GitHub repos, which allow us to remix
and freely link other dependent packages so we can debug right through our
deps.  I agree we need more stability around the release/publish steps so
we can move more quickly through the collection of packages that make up a
'tools' release.

@purplecabbage
risingj.com


On Fri, Sep 14, 2018 at 2:56 PM  wrote:


No. This won't fix anything. Plus it goes directly against npm's
recommendation. Please double check the docs for the use cases of
package-lock.json vs npm-shrinkwrap.json.

Am Fr., 14. Sep. 2018 um 23:48 Uhr schrieb Chris Brody <
chris.br...@gmail.com>:


A really nice alternative may be to turn the generated
package-lock.json into npm-shrinkwrap.json (using npm shrinkwrap
command) then commit npm-shrinkwrap.json. Then I think any other npm
install updates would update npm-shrinkwrap.json instead of
package-lock.json. Could be more predictable and easier to understand.

This was already discussed in 2014 [1], thanks to Jesse for the link in
[2].

Thanks for the suggestion to use npm shrinkwrap as a solution for
cordova-cli 8.1.0 minor release in [2].

[1]


https://lists.apache.org/thread.html/99184622129935eb473e843e583bf6648faff279a014e8508cc2c660@1411013202@%3Cdev.cordova.apache.org%3E

[2]


https://lists.apache.org/thread.html/f89a074add24f2ace7006b0211cf43a47cc5c1a0a65932fc22515828@%3Cdev.cordova.apache.org%3E

On Fri, Sep 14, 2018 at 3:53 PM Chris Brody 

wrote:

To be honest I have pretty limited experience with package lock file
and it is now starting to show. From Oliver's very unfortunate
experience I would conclude that this is something we should do very
carefully and not just on a whim. Some things I can think of:

* always use recent version of npm such as npm@6.4.1 to generate or
update package-lock.json
* do not use. npm cache when generating or updating

package-lock.json,

or use the npm cache with extreme care (also limited experience for
me)
* be extremely careful with assumptions; I think we should both
double-check the documentation and do our own experimentation, like I
did in <https://github.com/apache/cordova-cli/pull/325> to validate

as

best we can
* semver package seems to be a major library package used by npm; we
should both read the documentation and experiment, ideally with its
own test cases

On Fri, Sep 14, 2018 at 9:47 AM Oliver Salzburg
 wrote:

The problems that appear when you have linked dependencies is that

npm

will pick them up as being bundled and mark them as such in the
lockfile. *However* this behavior has changed in the past. At one

point

this affected any direct dependency, at another point it "only"

affected

dependencies of dependencies.

Either way, the result is:

a) a corrupted lockfile, which has dependencies marked as bundled
b) a lockfile that lists incorrect versions, resulting from linking
temporary development snapshots together

When you use a local npm cache and you neglected to correctly
parameterize your npm calls, you now have your custom registry URL

in

the lockfile for every package it installed from there. This makes

it

unusable for others.

The issue that ultimately drove us away from this concept was that
locally cached packages were installed over linked modules, because

the

package manager did not understand that they are linked.
But because they were linked, the cached package contents were

placed

in

my local development checkout of that linked module. That obviously
caused all uncommitted changes to be deleted.

Additionally, if you already have linked modules set up, but the
lockfile says that a certain dependency is to be replaced, it will

just

break your link or replace your linked code as soon as you `npm

install`.

We had so many issues with this, I'm sure I'm only remembering the

tip

of the ice berg. Maybe all of this wa

Re: Commit package-lock.json in next major Cordova release or not?

[Oliver Salzburg]

I would also suggest to have a brief look at the issues other users are 
reporting regarding this:


- https://github.com/npm/npm/issues?utf8=%E2%9C%93=is%3Aissue+package-lock
- https://npm.community/search?q=package-lock%20category%3A6

Of course, in the end, nothing beats a validation against own targets. 
I'm probably the wrong guy for that job though :D


On 2018-09-14 21:53, Chris Brody wrote:

To be honest I have pretty limited experience with package lock file
and it is now starting to show. From Oliver's very unfortunate
experience I would conclude that this is something we should do very
carefully and not just on a whim. Some things I can think of:

* always use recent version of npm such as npm@6.4.1 to generate or
update package-lock.json
* do not use. npm cache when generating or updating package-lock.json,
or use the npm cache with extreme care (also limited experience for
me)
* be extremely careful with assumptions; I think we should both
double-check the documentation and do our own experimentation, like I
did in <https://github.com/apache/cordova-cli/pull/325> to validate as
best we can
* semver package seems to be a major library package used by npm; we
should both read the documentation and experiment, ideally with its
own test cases

On Fri, Sep 14, 2018 at 9:47 AM Oliver Salzburg
 wrote:

The problems that appear when you have linked dependencies is that npm
will pick them up as being bundled and mark them as such in the
lockfile. *However* this behavior has changed in the past. At one point
this affected any direct dependency, at another point it "only" affected
dependencies of dependencies.

Either way, the result is:

a) a corrupted lockfile, which has dependencies marked as bundled
b) a lockfile that lists incorrect versions, resulting from linking
temporary development snapshots together

When you use a local npm cache and you neglected to correctly
parameterize your npm calls, you now have your custom registry URL in
the lockfile for every package it installed from there. This makes it
unusable for others.

The issue that ultimately drove us away from this concept was that
locally cached packages were installed over linked modules, because the
package manager did not understand that they are linked.
But because they were linked, the cached package contents were placed in
my local development checkout of that linked module. That obviously
caused all uncommitted changes to be deleted.

Additionally, if you already have linked modules set up, but the
lockfile says that a certain dependency is to be replaced, it will just
break your link or replace your linked code as soon as you `npm install`.

We had so many issues with this, I'm sure I'm only remembering the tip
of the ice berg. Maybe all of this was fixed somehow, but I doubt it. At
the time when I reported these issues, there was little interest in
resolving them.

However, I'm not unfamiliar with the lockfile-driven workflow as many
OSS projects I contributed to use it. It is not uncommon to completely
wipe your node_modules and/or package-lock.json to rebuild it, because
of corruptions in either entity. And that is something that has been
confirmed to me many times by other developers. As in "That's just how
it is."

This entire area of issues was not exclusive to npm either. We
extensively evaluated yarn regarding these aspects and it performed just
as poorly.

I consider these aspects unacceptable for a development workflow as they
introduce an unreliability where I can't have one.

If someone came out and told me "Hey, you've been doing it wrong all
along. These are your mistakes and this is how you resolve them." then
I'd be very happy to hear that :)

On 2018-09-14 15:13, raphine...@gmail.com wrote:

Thanks for picking this up again Chris. I think now is a better time for
second thoughts than later.

I've had a look at your experiment and the behavior you observed is to be
expected and desirable, as I explained in more detail in a comment [1]
there. As I also mentioned there, deleting and regenerating package-lock.json
is a valid approach _if and when_ you want to do a full dependency update,
as we regularly do.

Also, thanks for posting Oliver's message here for better visibility in
this discussion. What I _do_ find a bit disturbing is the problems he
mentioned regarding linking (as in `npm link`) of different modules which
are all using lock files. He expressed his concern regarding that
particular use-case again in a comment [2] of a PR where we touched that
topic. I think it is important we test this, since the ability to link
modules is vital for our development workflow and I have no experience with
package-lock.json in projects where a lot of linking is necessary.

Finally, I think we might need to re-evaluate our presumed knowledge about
the topic at hand. I encourage all those interested to read [3][4][5] so we
all know what we are talking about. I had my facts wrong too and

Re: [DISCUSS cordova-windows@6.0.1 patch release

[Oliver Salzburg]

What kind of verification is expected for these types of changes?

#285 only adds a license header. That looks pretty safe to me.
#287 I have a hard time seeing any relevant changes either. The 
references to C:/Users/brodybits/Documents seem weird.


#281 seems to be the only relevant change at all and it's massive.
To validate, I opted to install 6.1.0-nightly.2018.9.16.d424e99a into 
our app to see how that goes, as I assumed the relevant changes would be 
in that nightly.
The app prepares from scratch nicely, but will fail upon startup due to 
missing WinJS in a plugin:


Unhandled exception at line 690, column 1 in 
ms-appx-web://40934hartwigcommunication.eventhub2017-youreventco/www/plugins/fairmanager-cordova-plugin-barcodescanner/src/windows/BarcodeScannerProxy.js

0x800a1391 - JavaScript runtime error: 'WinJS' is undefined occurred

Maybe the nightly was not a great choice. Do we have a pre-relase tag 
for this 6.0.1 for easier verification?



On 2018-09-17 01:06, Chris Brody wrote:

Thanks Julio.

Considering that this is a *patch* release, issued to resolve a few
issues, I would really favor a quick review from a couple
cordova-windows experts to ensure that I didn't break anything major.

Changes are from the following PRs:
* https://github.com/apache/cordova-windows/pull/287
* https://github.com/apache/cordova-windows/pull/285
* https://github.com/apache/cordova-windows/pull/281
On Sun, Sep 16, 2018 at 6:55 PM julio cesar sanchez
 wrote:

Just a reminder that any discussion about a release should be done on the
discuss thread and not on the vote thread, even if the comment is to try to
get more votes for that release. Vote threads should only be used to vote,
and close the vote once it reaches the minimum number of votes.

So Brody still needs some votes for this release.

Looks like some of you had some troubles testing, that could be -1 votes if
you think something is not right.





El jue., 16 ago. 2018 a las 10:59, Shazron () escribió:


I'm still investigating this splashscreen issue -- not sure if
something broke, or I haven't defined something
(am n00b on Windows platform...)
On Wed, Aug 15, 2018 at 4:19 PM Jan Piotrowski 
wrote:

I had to set the MSBUILDDIR env var explicitly to C:\Program Files
(x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin since
our code fails to detect the MSBuild version installed with that,
v15.8.

The registry entry it checks still has MSBuild v4 from the .NET
Framework -- so perhaps our detection is outdated.

 From what I remember our MSBuild detection logic is a bit more
complicated and does many, many things to find it.
My best guess here is that somewhere `15.8` would have to be added to
a list - when cordova-windows 6.0.0 was released the correct MSBuild
was autodetected.
Should probably be rewritten completely :/


I had also noticed this issue, with Visual Studio 2017, from our

AppVeyor tests.

The AppVeyor configuration is set to accept the failures as a passing

result if using Visual Studio 2017.

I had been wanting to fix this so the tests would actually run and

pass properly but didn’t have too much time to look into this.

AppVeyor fails for Visual Studio 2017 because of one unexplained test
failure, that only happens on CI.
(I thought there already was an issue, seems I was wrong. Created
https://github.com/apache/cordova-windows/issues/290).

J

2018-08-15 8:16 GMT+02:00 Bryan Ellis :

I had also noticed this issue, with Visual Studio 2017, from our

AppVeyor tests.



https://ci.appveyor.com/project/Humbedooh/cordova-windows/build/1.0.1020

The AppVeyor configuration is set to accept the failures as a passing

result if using Visual Studio 2017.

I had been wanting to fix this so the tests would actually run and

pass properly but didn’t have too much time to look into this.



On Aug 15, 2018, at 14:54, Shazron  wrote:

https://github.com/apache/cordova-windows/issues/274 which is not a
blocker IMO, but I'm not sure of the splash screen. Technically the
app builds and runs...
On Wed, Aug 15, 2018 at 1:40 PM Shazron  wrote:

You can debug what requirements it tries to detect for MSBUILD by

running:

cordova requirements --verbose
On Wed, Aug 15, 2018 at 1:39 PM Shazron  wrote:

Repro steps:

```
npm install -g cordova
cordova create foo
cd foo
cordova platform add

https://github.com/apache/cordova-windows#6.0.1

cordova run
```

Pre-requisites:
- Visual Studio 2017 Community installed with defaults
- Windows 10 SDK
- Set env var `MSBUILDDIR` to 'C:\Program Files
(x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin'

On Wed, Aug 15, 2018 at 1:36 PM Shazron  wrote:

Had trouble meeting the requirements to build, using VS 2017

Community edition

I had to set the MSBUILDDIR env var explicitly to C:\Program Files
(x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin since
our code fails to detect the MSBuild version installed with that,
v15.8.

The registry entry it checks still has MSBuild v4 from the .NET

Re: Commit package-lock.json in next major Cordova release or not?

[Oliver Salzburg]

The problems that appear when you have linked dependencies is that npm 
will pick them up as being bundled and mark them as such in the 
lockfile. *However* this behavior has changed in the past. At one point 
this affected any direct dependency, at another point it "only" affected 
dependencies of dependencies.


Either way, the result is:

a) a corrupted lockfile, which has dependencies marked as bundled
b) a lockfile that lists incorrect versions, resulting from linking 
temporary development snapshots together


When you use a local npm cache and you neglected to correctly 
parameterize your npm calls, you now have your custom registry URL in 
the lockfile for every package it installed from there. This makes it 
unusable for others.


The issue that ultimately drove us away from this concept was that 
locally cached packages were installed over linked modules, because the 
package manager did not understand that they are linked.
But because they were linked, the cached package contents were placed in 
my local development checkout of that linked module. That obviously 
caused all uncommitted changes to be deleted.


Additionally, if you already have linked modules set up, but the 
lockfile says that a certain dependency is to be replaced, it will just 
break your link or replace your linked code as soon as you `npm install`.


We had so many issues with this, I'm sure I'm only remembering the tip 
of the ice berg. Maybe all of this was fixed somehow, but I doubt it. At 
the time when I reported these issues, there was little interest in 
resolving them.


However, I'm not unfamiliar with the lockfile-driven workflow as many 
OSS projects I contributed to use it. It is not uncommon to completely 
wipe your node_modules and/or package-lock.json to rebuild it, because 
of corruptions in either entity. And that is something that has been 
confirmed to me many times by other developers. As in "That's just how 
it is."


This entire area of issues was not exclusive to npm either. We 
extensively evaluated yarn regarding these aspects and it performed just 
as poorly.


I consider these aspects unacceptable for a development workflow as they 
introduce an unreliability where I can't have one.


If someone came out and told me "Hey, you've been doing it wrong all 
along. These are your mistakes and this is how you resolve them." then 
I'd be very happy to hear that :)


On 2018-09-14 15:13, raphine...@gmail.com wrote:

Thanks for picking this up again Chris. I think now is a better time for
second thoughts than later.

I've had a look at your experiment and the behavior you observed is to be
expected and desirable, as I explained in more detail in a comment [1]
there. As I also mentioned there, deleting and regenerating package-lock.json
is a valid approach _if and when_ you want to do a full dependency update,
as we regularly do.

Also, thanks for posting Oliver's message here for better visibility in
this discussion. What I _do_ find a bit disturbing is the problems he
mentioned regarding linking (as in `npm link`) of different modules which
are all using lock files. He expressed his concern regarding that
particular use-case again in a comment [2] of a PR where we touched that
topic. I think it is important we test this, since the ability to link
modules is vital for our development workflow and I have no experience with
package-lock.json in projects where a lot of linking is necessary.

Finally, I think we might need to re-evaluate our presumed knowledge about
the topic at hand. I encourage all those interested to read [3][4][5] so we
all know what we are talking about. I had my facts wrong too and nobody
corrected me, when I uttered them here in this thread. So here's a quick
(probably incomplete) round up of what package-lock.json does and does not
do:

- It does provide a snapshot of the dependency tree that can be
committed into source control to avoid automatic updates of (transitive)
dependencies break the build _during development and CI_
- It _does not_ ensure that a user installing the published package gets
exactly the dependency versions that are specified in package-lock.json.
That is what npm-shrinkwrap.json [5] is for.
- It does speed up installation of dependencies in conjunction with `npm
ci` by skipping the entire dependency resolution and using the versions
from the lock file.
- It is required to be present for `npm audit` [6], although it could be
generated ad-hoc.
- It is possible to manually tinker with the lock file to fix audit
issues with transitive dependencies that have no update available. This
requires some special care to prevent npm from resetting these manual
changes, but it's a valuable last-resort option. However, this is far more
useful with npm-shrinkwrap.json to create releases without security
issues.

With that cleared up, my stance on committing package-lock.json is as
follows:

- Faster CI 

Re: [DISCUSS] Update dependencies for nightly builds in master

[Oliver Salzburg]

Yes, that makes sense. What I meant was the opposite: When specifying a 
range, it should not be fulfilled with a suffixed version.


On 2018-09-13 16:20, Chris Brody wrote:

If I would try the following command in master branch of
cordova-common (just an experiment):

 npm install cordova-common@^3.0.0-nightly

I would see the following change in package.json:

"dependencies": {
-"cordova-common": "^2.2.0",
+"cordova-common": "^3.0.0-nightly.2018.9.13.9c6cda3d",

Next experiment (again just an experiment): remove generated
node_modules and package-lock.json artifacts (package-lock.json is not
yet committed in cordova-common and update package.json as follows:

diff --git a/package.json b/package.json
index 9f3bdc23..e488c149 100644
--- a/package.json
+++ b/package.json
@@ -19,3 +19,3 @@
"dependencies": {
-"cordova-common": "^2.2.0",
+"cordova-common": "^3.0.0-nightly",
  "cordova-create": "^1.1.0",

then after npm install I get the following result from grep version
node_modules/cordova-common/package.json:

   "version": "3.0.0-nightly.2018.9.13.9c6cda3d"

One more experiment: if I would try the following change to package.json:

diff --git a/package.json b/package.json
index 9f3bdc23..01c549dc 100644
--- a/package.json
+++ b/package.json
@@ -19,3 +19,3 @@
"dependencies": {
-"cordova-common": "^2.2.0",
+"cordova-common": "^2.2.1-nightly",
  "cordova-create": "^1.1.0",

then do clean npm install (node_modules and package-lock.json
artifacts removed) I get the following result from grep version
node_modules/cordova-common/package.json:

   "version": "2.2.5"

These results indicate to me that depending on "-rc" version with
caret (^) should do what we want: use latest "-rc" version available
until we publish the major release, and then use the major release.

FYI this seems to be documented in
https://github.com/npm/node-semver#prerelease-tags which is linked by
https://semver.npmjs.com/.




-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Cordova 8.1.0 (minor release) proposal

[Oliver Salzburg]

I feel like this would help move things forward. So I'm in favor.


On 2018-09-14 08:24, Chris Brody wrote:

I would like to propose making 8.1.0 minor release, which would consist of:
* new cordova-lib@8.1.0 minor release
* new cordova-cli@8.1.0 minor release

to accomplish the following:
* resolve npm audit issues that show up in cordova-lib@8.0.0 & cordova-cli@8.0.0
* support cordova-android@~7.1.x and cordova-windows@~6.0.x releases by default
* stable AppVeyor CI & Travis CI builds

I already raised the proposal on cordova-lib in:
https://github.com/apache/cordova-lib/pull/693

For cordova-cli the major items would be to update insight, to resolve
npm audit issues, and use new cordova-lib@8.1.0 minor release.

Feedback would be appreciated whether this minor release is wanted,
patch release is really needed for some reason, or if we should wait
for the next major release.

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DISCUSS] Update dependencies for nightly builds in master

[Oliver Salzburg]

To my understanding, any suffixed version is never matched by a range. 
They have to be targeted explicitly.


This can be easily observed at https://semver.npmjs.com/ by entering no 
range or *


On 2018-09-13 12:53, Chris Brody wrote:

I would really favor the idea of publishing -rc suffixed versions to
resolve the dilemma discussed here. I would favor starting with something
like -rc.01 which could gracefully handle up to 99 rc versions.

Assuming that -rc suffixed versions should be considered stable enough for
master then using caret (^) in dependencies means that we should be able to
do this just once per Cordova package in a major release.

On Thu, Sep 13, 2018, 6:08 AM Oliver Salzburg 
wrote:


Alright, as long as we're talking about a manual process to resolve this
conflict temporarily, I see it as a valid suggestion.
However, I would still prefer if a -rc.0 suffixed version was published
and then depended upon, for clarity.

On 2018-09-13 11:49, Jan Piotrowski wrote:

Chris didn't really mention the actual problem he tried to solve with
this PR in his initial email, and half the discussion here was about
something totally different.

My understanding of what he did was that he tried to find a way to
test a new version of corova-create that requires new versions of
cordova-fetch and cordova-common, which have necessary updates in
master but that have not been released to npm yet. Setting the
dependencies to nightly releases theoretically makes this possible.

An alternative solution of course is to create releases for
cordova-fetch and cordova-common first, then update cordova-create to
use those.

Stumbling block here is that Cordova package releases seem to be a big
deal, historically, and quite some process to follow.
If we find a way to make cutting a release of a library a quick and
simple thing, this should be much less of an issue. Correct?

-J



-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DISCUSS] Update dependencies for nightly builds in master

[Oliver Salzburg]

Alright, as long as we're talking about a manual process to resolve this 
conflict temporarily, I see it as a valid suggestion.
However, I would still prefer if a -rc.0 suffixed version was published 
and then depended upon, for clarity.


On 2018-09-13 11:49, Jan Piotrowski wrote:

Chris didn't really mention the actual problem he tried to solve with
this PR in his initial email, and half the discussion here was about
something totally different.

My understanding of what he did was that he tried to find a way to
test a new version of corova-create that requires new versions of
cordova-fetch and cordova-common, which have necessary updates in
master but that have not been released to npm yet. Setting the
dependencies to nightly releases theoretically makes this possible.

An alternative solution of course is to create releases for
cordova-fetch and cordova-common first, then update cordova-create to
use those.

Stumbling block here is that Cordova package releases seem to be a big
deal, historically, and quite some process to follow.
If we find a way to make cutting a release of a library a quick and
simple thing, this should be much less of an issue. Correct?

-J




-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DISCUSS] Update dependencies for nightly builds in master

[Oliver Salzburg]

On 2018-09-13 00:34, Chris Brody wrote:


In case of major version bump each Cordova package will continue to
keep dependency on previous patch release of other packages until we
make the new release.

Reading this makes me think I didn't understand an important part of the 
discussion. Isn't this basic semantic versioning?


If you have a 1.x of your main package, you want to release 2.x and you 
have a dependency of which you want to include a newer version than is 
covered by your current semver range, then update the range in your 
package.json before you release 2.x.


There is also nothing wrong with bumping dependency semver ranges in a 
module in master. Then you can install the new dependency version when 
you pull the latest changes and update your dependencies. This should 
obviously only be done when there was an important change in the 
dependency that is required in master.


This seems very obvious and is covered thoroughly in at least the 
documentation of npm. What am I missing?


-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DISCUSS] Update dependencies for nightly builds in master

[Oliver Salzburg]

On 2018-09-12 22:40, Jan Piotrowski wrote:
> cordova-create uses cordova-common and cordova-fetch. Right now two
> existing releases are pinned as dependencies. cordova-common and
> cordova-fetch have changes in master, that are necessary for new
> things in cordova-create to work. Right now there is no way to change
> cordova-create to do this. Using nightly of cordova-comand and
> cordova-fetch would enable this. Correct?

Why not just publish the new version? I mean, properly, not a -nightly.

Then the projects could depend on these new versions on work properly in
master as well.

For the time being, the -nightly release would work fine for the
purpose, but something like that should be occasional, not regular. I
believe the latter case would produce more failures than it solves.

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DISCUSS] Update dependencies for nightly builds in master

[Oliver Salzburg]

On 2018-09-12 22:31, raphine...@gmail.com wrote:
> Yeah, I mean that's what we do with the nightlies already. I agree that it
> would be great to be notified of integration problems ASAP. But to achieve
> that, we should test the nightlies produced during the nightly build.

On 2018-09-12 21:36, Jan Piotrowski wrote:
> How do other libraries handle this inter-connectedness between libraries?

That is what we do. We don't produce nightly builds, we trigger
integration jobs on each build of a dependency. The integration job
checks the latest snapshot of the dependency against its dependents.

That's a bit of work to set up, but I would rather just not do it at all
then start committing nightly versions into your dependency tree. This
will lead to you constantly having to rebuild your local dependency tree
on every git pull.

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DISCUSS] Update dependencies for nightly builds in master

[Oliver Salzburg]

On 2018-09-12 21:29, Chris Brody wrote:
> I think this would give us better integrity of nightly builds.

I don't think I understand the proposal.

If the goal is to produce nightly builds, why not change the dependency
version during the nightly build, publish the nightly and leave master
dependent on the stable dependency?

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Status of Next Major

[Oliver Salzburg]

I just wanted to voice my concern regarding package-locks on the list, 
even though consensus was probably reached in the past already.


From our experience, this is almost as bad as committing node_modules 
into VCS.
I understand the idea behind them and I would agree with that idea, but 
the implementation is horrible and suffers from many defects that 
ultimately lead to developer frustration and hard-to-analyze bugs.


Especially during development where you might switch between package 
versions or link locally against development checkouts of modules, 
package-lock files constantly get corrupted or operations even lead to 
local development checkouts being replaced by cached npm modules, 
because the lockfile had them marked as bundled.
And anytime something like that happens, you're left with having to 
rebuild the lockfile from scratch, introducing exactly the changes you 
didn't want in the first place.


I understand that `npm ci` can have performance benefits during 
installation of packages, but the underlying technologies are defective, 
the time you save in CI will be spent by developers instead and you'll 
likely roll back or have to deal with blocking npm issues for some time.


That was the experience for us and I'd hate to see others make the same 
mistake. If you go with it, I hope it works better for you and maybe I 
will learn how it was all our own fault all along and we've just been 
holding our iPhone the wrong way. :D


Cheers


On 2018-09-11 08:14, Bryan Ellis wrote:

Hey, how is everyone doing?

As it is getting closer to the middle of September, I wanted to catch up
and get a status update on how everyone is doing for the next major.

Blow, I re-listed out the idea items for next major goals that were
mentioned in a previous email.
*https://mail-archives.apache.org/mod_mbox/cordova-dev/201808.mbox/%3CCA+z8NA-tQJqqAFR0fJni7PzRG7LP3O0CbpqSytFHWYZefQb=-a...@mail.gmail.com%3E
*

I also want to point out that these items and others on next next major
were added to the *"Apache Cordova: Next Release Planning and Tracking"*
project board. *https://github.com/orgs/apache/projects/2
*

*Done*
**
* Remove usage of cordova-registry-mapper from tooling
* Remove all old `--no-fetch` code
* Refactor the cordova-fetch code to improve performance
* Android: Adaptive Icons support
* iOS: Fix for automatic provisioning
* iOS: Improved Swift support
* iOS: Fix CocoaPods Pathing Issue & Xcode 10 build (
https://github.com/apache/cordova-ios/pull/398)

*In Progress*
*===*
* iOS: CocoaPods Support Improvement (
https://github.com/apache/cordova-ios/issues/391)
* Drop node 4 support from all repos
* Drop committed node_modules from all platform repos
* iOS: Bridge WebView plugin for WKWebView transition
* Update the Hello Cordova starter to work with WKWebView & safe areas

*To Do*
*=*
* Commit package-lock.json in repos
* iOS: Anything required for iOS 12 support
* Android: Bring whitelist in-platform

*Observation Items (Not an original task)*
*=*
  * ios-deploy: Xcode 10 & iOS 12 issue (ImportError: cannot import name
_remove_dead_weakref)




-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Contributing to Cordova

[Oliver Salzburg]

Hello list,

we've been working with Cordova for about a year now.
In the process we've opened a couple of issues on the Cordova Jira and
submitted a couple of pull requests on GitHub.

I've noticed that responses to these actions usually take either a very
long time, or don't happen at all.

We've started to maintain forks of several plugins where we have
included required fixes, but I consider this a very sad situation.
I would much prefer to use upstream versions and have our fixes
included in those.

So I'm wondering if I'm not using the correct communication channels.

Please let me know about the best way to have contributions discussed
and included quickly.

Thanks in advance,
Oliver

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org