Re: Plugins and Node.js versions
Sounds good to me. Faster CI is better CI On Thu, May 16, 2019 at 2:16 PM Jan Piotrowski wrote: > None of the plugins have a `hooks` directory or anything else that > looks similar. > > Is anyone aware of any script in the plugin repositories that is > executed on the developer side? > > Otherwise I think we should be good to define adding and dropping > Node.js versions as non-breaking for plugins. > > Best, > Jan > > Am Sa., 11. Mai 2019 um 10:49 Uhr schrieb : > > > > Sounds like a good idea under the premise that our plugins really do not > > contain any scripts that > > are executed on the developer machine. > > > > But aren't there any core plugins that define hooks? > > > > Am Sa., 11. Mai 2019 um 10:03 Uhr schrieb Jan Piotrowski < > > piotrow...@gmail.com>: > > > > > Currently our plugin CI uses the same version of Node.js as Tooling > > > and Platforms, until recently 4.2 and now 6. > > > > > > But if I am not mistaken, our plugins do not contain any scripts that > > > are executed on the developer machine, only JavaScript files that are > > > run inside the app or native code. So it doesn't really matter what > > > node version is used to run our plugin CI tests as it doesn't run any > > > actual scripts (vs. with platforms, we have scripts that are actually > > > run by the developer). > > > > > > Could we maybe just go to node 10 or 12 with our plugins right now? > > > > > > This would give as quite some time until we have to update our CI > > > configuration again, and possibly also quicker installs and builds. > > > > > > Best, > > > Jan > > > > > > - > > > 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 > >
Nightly build #1093 for cordova has succeeded!
Nightly build #1093 for cordova has succeeded! The latest nightly has been published and you can try it out with 'npm i -g cordova@nightly' For details check build console at https://builds.apache.org/job/cordova-nightly/1093/consoleFull - Jenkins for Apache Cordova - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: Plugins and Node.js versions
None of the plugins have a `hooks` directory or anything else that looks similar. Is anyone aware of any script in the plugin repositories that is executed on the developer side? Otherwise I think we should be good to define adding and dropping Node.js versions as non-breaking for plugins. Best, Jan Am Sa., 11. Mai 2019 um 10:49 Uhr schrieb : > > Sounds like a good idea under the premise that our plugins really do not > contain any scripts that > are executed on the developer machine. > > But aren't there any core plugins that define hooks? > > Am Sa., 11. Mai 2019 um 10:03 Uhr schrieb Jan Piotrowski < > piotrow...@gmail.com>: > > > Currently our plugin CI uses the same version of Node.js as Tooling > > and Platforms, until recently 4.2 and now 6. > > > > But if I am not mistaken, our plugins do not contain any scripts that > > are executed on the developer machine, only JavaScript files that are > > run inside the app or native code. So it doesn't really matter what > > node version is used to run our plugin CI tests as it doesn't run any > > actual scripts (vs. with platforms, we have scripts that are actually > > run by the developer). > > > > Could we maybe just go to node 10 or 12 with our plugins right now? > > > > This would give as quite some time until we have to update our CI > > configuration again, and possibly also quicker installs and builds. > > > > Best, > > Jan > > > > - > > 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] coho: Change the default folder it works on
#237 Seems sufficient to me. Remember that coho has very limited use and is not really intended for wide adoption. It is for developers working with the collection of cordova repos, and managing the multitude of repos that we have. Personally, I don't see a ton of value in changing it. On Thu, May 16, 2019 at 3:08 AM Jan Piotrowski wrote: > While rewriting the plugin release documentation, I stumbled over the > way coho chooses the directory where it does its changes. As this is > probably just because of historical reasons, I suggest we change the > way it works: > > https://github.com/apache/cordova-coho/issues/238 > > Is there any reason to keep the old behavior? > Any use case that is used frequently but that I missed that depends on > it working this way? > > If there are no replies that suggest otherwise, I will go forward with > the issue some time next week. > > Best, > Jan > > - > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > >
[DISCUSS] coho: Change the default folder it works on
While rewriting the plugin release documentation, I stumbled over the way coho chooses the directory where it does its changes. As this is probably just because of historical reasons, I suggest we change the way it works: https://github.com/apache/cordova-coho/issues/238 Is there any reason to keep the old behavior? Any use case that is used frequently but that I missed that depends on it working this way? If there are no replies that suggest otherwise, I will go forward with the issue some time next week. Best, Jan - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
[VOTE] cordova-plugin-vibration Release 3.1.1
Please review and vote on the release of this plugins release by replying to this email (and keep discussion on the DISCUSS thread) The plugins have been published to dist/dev: https://dist.apache.org/repos/dist/dev/cordova/cordova-plugin-vibration%2381/ The packages were published from their corresponding git tags: cordova-plugin-vibration: 3.1.1 (524ad47f2d) Upon a successful vote I will upload the archives to dist/, upload them to npm, and post the corresponding blog post. Voting guidelines: https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md How to vote on a plugins release at https://github.com/apache/cordova-coho/blob/master/docs/plugins-release-process.md#voting 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
Re: [DISCUSS] Remove all documentation translations
+1 to what Jan said Jan Piotrowski schrieb am Do., 16. Mai 2019, 10:54: > I would say "No" to 1) and 3) - we can get rid of the code and > deactivate that account. > > 2) and 4) definitely need their own mailing list thread with their own > reasoning. > > -J > > Am Do., 16. Mai 2019 um 07:19 Uhr schrieb Dmitry Blotsky > : > > > > Ok, if that’s reality, then it’s reality. Then, if we’re on the topic of > dropping translations, let’s revisit the whole commitment. > > > > I’d be interested to know: > > 1. Do we want to keep the Crowdin account? > > 2. How many versions of docs are we keeping? Maybe we can prune some. > > 3. Do we want to keep support for translations for the future? Removing > it would allow us to delete a lot of code, but also would be harder to > bring back. > > 4. Do we even have a supported versions list? An LTS? If not, maybe > let’s start. > > > > What do you all think? > > > > Dmitry > > > > > On May 15, 2019, at 09:54, Darryl Pogue wrote: > > > > > >> On Wed, May 15, 2019 at 9:24 AM Dmitry Blotsky < > dmitry.blot...@gmail.com> wrote: > > >> > > >> Would anyone that works on Cordova full-time be up to prioritise this? > > > > > > As far as I know, there has been nobody working full-time on Cordova > > > for the past year. There are a few companies putting some dev time > > > against the project, but it's almost entirely maintained by people in > > > their limited spare time nowadays. > > > > > > - > > > 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] Remove all documentation translations
I would say "No" to 1) and 3) - we can get rid of the code and deactivate that account. 2) and 4) definitely need their own mailing list thread with their own reasoning. -J Am Do., 16. Mai 2019 um 07:19 Uhr schrieb Dmitry Blotsky : > > Ok, if that’s reality, then it’s reality. Then, if we’re on the topic of > dropping translations, let’s revisit the whole commitment. > > I’d be interested to know: > 1. Do we want to keep the Crowdin account? > 2. How many versions of docs are we keeping? Maybe we can prune some. > 3. Do we want to keep support for translations for the future? Removing it > would allow us to delete a lot of code, but also would be harder to bring > back. > 4. Do we even have a supported versions list? An LTS? If not, maybe let’s > start. > > What do you all think? > > Dmitry > > > On May 15, 2019, at 09:54, Darryl Pogue wrote: > > > >> On Wed, May 15, 2019 at 9:24 AM Dmitry Blotsky > >> wrote: > >> > >> Would anyone that works on Cordova full-time be up to prioritise this? > > > > As far as I know, there has been nobody working full-time on Cordova > > for the past year. There are a few companies putting some dev time > > against the project, but it's almost entirely maintained by people in > > their limited spare time nowadays. > > > > - > > 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: Best place to post questions about Cordova WKWebView support?
I don’t think there is a better place, but I definitely wouldn’t recommend people asking on Cordova GitHub repositories, nor the dev list unless it’s to talk about how we could try to fix or workaround those issues that affect cordova-ios (if that was possible somehow). The phonegap Google group has no activity anymore. For quick answers probably the better place is the Cordova slack, but stack Overflow should be better to not lose the answers in the future as slack has a 1 message limit. Anyway, that assumes people uses the search features on those sites, which is not always true. Also, looks like Apple people seems to be more active on Twitter lately and sometimes answer to people complaining about WebKit/WKWebView, but most times they will tell you to file an issue so they can try to fix it. I don’t really like when people use Twitter to complain about Cordova issues instead of repotting them, so wouldn’t recommend it neither. El jueves, 16 de mayo de 2019, Chris Brody escribió: > For issues with features such as XHR and DOM references? > > I can think of the following places: > > * https://github.com/apache/cordova-ios/issues > * https://github.com/apache/cordova/issues > * phone...@googlegroups.com > * mailto: dev@cordova.apache.org (this forum) > * StackOverflow (my experience with getting urgent, tough questions > answered on StackOverflow has not been so good) > > - > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > >
Re: [DISCUSS] non-global Cordova installs
In Capacitor docs (from ionic), npx is user everywhere https://capacitor.ionicframework.com/ El jueves, 16 de mayo de 2019, Jesse escribió: > I think there is a disconnect on the actual proposal here. > > Here's the pr again ( keep the discussion here please ) > https://github.com/apache/cordova-docs/pull/987/files > > The only real use of npx as a one-off command would be the call to create a > new app. ie. `npx cordova create dirname ...` > The instructions after that are to cd into the dir, and install cordova > locally. > All npx calls after that are run from inside a project folder and are just > the same as npm run commands, they access the binary exported in > node_modules/cordova > > That said, I do still think npx should be presented as an alternative, and > not necessarily the 'preferred' way. > > > > > > > On Wed, May 15, 2019 at 10:38 PM Dmitry Blotsky > wrote: > > > In terms of exposure, btw, npx is indeed strictly worse than npm install. > > It checks for dependencies, installs them, and runs them: all at every > call > > of a command. That is more frequent than how often anyone runs npm > install, > > and is more overhead than running a shell command directly. > > > > From a higher-up perspective though: every other software ecosystem gets > > by with just running commands in a shell. How is our situation so > > outlandish that the most time-tested tools don’t meet our command-running > > needs? > > > > Dmitry > > > > > On May 15, 2019, at 22:29, Dmitry Blotsky > > wrote: > > > > > > If it’s any convincing data: none of React Native, Ionic, Angular, > > Ember, Meteor, or Vue mention npx. > > > > > > They all recommend npm install -g or some variant using more mature > > tools. > > > > > > I agree that it would be a piece of cake for us to instruct people to > > install cordova for the local user, or to use per-project installs of > > cordova. These options are all still pretty convenient, and don’t incur > the > > security penalties of npx. > > > > > > Dmitry > > > > > >> On May 15, 2019, at 02:15, Jesse wrote: > > >> > > >> Given how contentious this has become, I think our best approach would > > be > > >> to continue with our global install expectation, and add documentation > > on > > >> a) what to do if you have issues with `npm i -g cordova` [1] > > >> b) document how to do local dependencies and use npx ( this might be a > > good > > >> blog post as well as permanent documentation ) > > >> > > >> Regarding some of the issues stated previously: > > >> > > Dmitry: 1. It is strictly less secure than the status quo, and all > > >> alternatives. .. > > >> The exposure to the user is no different than `npm install -g`, it is > > just > > >> harder to know exactly what is happening. > > >> > > Dmitry: 2. It is strictly less stable than a local installation ... > > >> Only the first `npx cordova create ...` will result in a fetch, > further > > >> uses of npx cordova will use the cached version, and can be done > > without a > > >> network connection. > > >> > > Darryl: Encouraging people to install Cordova globally causes issues > > >> when working on multiple projects ... > > >> Do we have a way of knowing how often this occurs? It sounds rare to > me. > > >> Regardless, there is no reason they can't go ahead install > > cordova@version > > >> as a dev dependency > > >> > > >> Personally, having read up on npx and done some basic tests, I am okay > > with > > >> it. However, I also don't feel we have to force it on everyone. > > >> We can suggest is as an alternative, and perhaps after we are all more > > >> comfortable with it, it can become the default. > > >> > > >> > > >> [1] > > >> > > https://docs.npmjs.com/resolving-eacces-permissions- > errors-when-installing-packages-globally > > >> > > >> > > >> > > >> > > >> On Tue, May 14, 2019 at 8:12 PM gandhi rajan > > > >> wrote: > > >> > > >>> Hi Dmitry, > > >>> > > >>> I second you on this. > > >>> > > On Tuesday, May 14, 2019, Dmitry Blotsky > > wrote: > > > > I'm really glad this discussion lit up, because it clearly shows > that > > >>> this > > issue isn't settled. > > > > I personally have few opinions about the "best" solution here, but I > > firmly believe that npx is a non-starter for these 2 reasons: > > 1. It is strictly less secure than the status quo, and all > > alternatives. > > It is literally downloading code from hundreds of untrusted parties > > and > > immediately running it. It's worse than piping a curl command into > > bash > > >>> (at > > least you can check the curl command's URL, or checksum the > downloaded > > script). > > 2. It is strictly less stable than a local installation because now > > every > > call to Cordova goes through an opaque dependency. > > > > Unless both of those can be addressed, I think we shouldn't consider > > npx. > > > > Dmitry > > > > > On May 10, 2019, at 4:31
Re: [DISCUSS] non-global Cordova installs
I think there is a disconnect on the actual proposal here. Here's the pr again ( keep the discussion here please ) https://github.com/apache/cordova-docs/pull/987/files The only real use of npx as a one-off command would be the call to create a new app. ie. `npx cordova create dirname ...` The instructions after that are to cd into the dir, and install cordova locally. All npx calls after that are run from inside a project folder and are just the same as npm run commands, they access the binary exported in node_modules/cordova That said, I do still think npx should be presented as an alternative, and not necessarily the 'preferred' way. On Wed, May 15, 2019 at 10:38 PM Dmitry Blotsky wrote: > In terms of exposure, btw, npx is indeed strictly worse than npm install. > It checks for dependencies, installs them, and runs them: all at every call > of a command. That is more frequent than how often anyone runs npm install, > and is more overhead than running a shell command directly. > > From a higher-up perspective though: every other software ecosystem gets > by with just running commands in a shell. How is our situation so > outlandish that the most time-tested tools don’t meet our command-running > needs? > > Dmitry > > > On May 15, 2019, at 22:29, Dmitry Blotsky > wrote: > > > > If it’s any convincing data: none of React Native, Ionic, Angular, > Ember, Meteor, or Vue mention npx. > > > > They all recommend npm install -g or some variant using more mature > tools. > > > > I agree that it would be a piece of cake for us to instruct people to > install cordova for the local user, or to use per-project installs of > cordova. These options are all still pretty convenient, and don’t incur the > security penalties of npx. > > > > Dmitry > > > >> On May 15, 2019, at 02:15, Jesse wrote: > >> > >> Given how contentious this has become, I think our best approach would > be > >> to continue with our global install expectation, and add documentation > on > >> a) what to do if you have issues with `npm i -g cordova` [1] > >> b) document how to do local dependencies and use npx ( this might be a > good > >> blog post as well as permanent documentation ) > >> > >> Regarding some of the issues stated previously: > >> > Dmitry: 1. It is strictly less secure than the status quo, and all > >> alternatives. .. > >> The exposure to the user is no different than `npm install -g`, it is > just > >> harder to know exactly what is happening. > >> > Dmitry: 2. It is strictly less stable than a local installation ... > >> Only the first `npx cordova create ...` will result in a fetch, further > >> uses of npx cordova will use the cached version, and can be done > without a > >> network connection. > >> > Darryl: Encouraging people to install Cordova globally causes issues > >> when working on multiple projects ... > >> Do we have a way of knowing how often this occurs? It sounds rare to me. > >> Regardless, there is no reason they can't go ahead install > cordova@version > >> as a dev dependency > >> > >> Personally, having read up on npx and done some basic tests, I am okay > with > >> it. However, I also don't feel we have to force it on everyone. > >> We can suggest is as an alternative, and perhaps after we are all more > >> comfortable with it, it can become the default. > >> > >> > >> [1] > >> > https://docs.npmjs.com/resolving-eacces-permissions-errors-when-installing-packages-globally > >> > >> > >> > >> > >> On Tue, May 14, 2019 at 8:12 PM gandhi rajan > >> wrote: > >> > >>> Hi Dmitry, > >>> > >>> I second you on this. > >>> > On Tuesday, May 14, 2019, Dmitry Blotsky > wrote: > > I'm really glad this discussion lit up, because it clearly shows that > >>> this > issue isn't settled. > > I personally have few opinions about the "best" solution here, but I > firmly believe that npx is a non-starter for these 2 reasons: > 1. It is strictly less secure than the status quo, and all > alternatives. > It is literally downloading code from hundreds of untrusted parties > and > immediately running it. It's worse than piping a curl command into > bash > >>> (at > least you can check the curl command's URL, or checksum the downloaded > script). > 2. It is strictly less stable than a local installation because now > every > call to Cordova goes through an opaque dependency. > > Unless both of those can be addressed, I think we shouldn't consider > npx. > > Dmitry > > > On May 10, 2019, at 4:31 PM, Oliver Salzburg < > >>> oliver.salzb...@gmail.com> > wrote: > > > > 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,
