Nightly build #850 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/850/consoleFull
-
Jenkins for Apache Cordova
+1
Thank you for the clarity! I am completely supportive of this.
@purplecabbage
risingj.com
On Fri, Sep 14, 2018 at 3:28 PM 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
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
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
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
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
Here's a similar discussion on the relative merits of shrinkwrap from 2014.
https://markmail.org/thread/osbvx53d3l5s6fsj
@purplecabbage
risingj.com
On Fri, Sep 14, 2018 at 2:04 PM Chris Brody wrote:
> A quick try of #6 worked for me, you can see the results in my
> cordova-cli WIP PR at:
A quick try of #6 worked for me, you can see the results in my
cordova-cli WIP PR at: https://github.com/apache/cordova-cli/pull/326
It is probably not the best: I simply edited npm-shrinkwrap.json by
hand, then npm install would update it further.
Resolves npm audit issues, runs on Node.js 4,
I'd really like to try #6. If that does not work as expected, we can still
go with #2.
Jan Piotrowski schrieb am Fr., 14. Sep. 2018, 21:47:
> #2 sounds absolutely fine to me as this dependency is in cordova-cli
> which is only used on developer machines, not included in any deployed
> packages.
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
#2 sounds absolutely fine to me as this dependency is in cordova-cli
which is only used on developer machines, not included in any deployed
packages.
Besides: Cordova has been shipping software with `npm audit` like
issues for ages and I don't think there has been a "totally
unacceptable in all
6. Use manually edited npm-shrinkwrap.json to force a more recent version
of `inquirer` ourselves. Little work, no audit warnings for the users. I
could do that when the branch is ready. However, we should test the whole
thing with a alpha suffix or something like that first.
Am Fr., 14. Sep.
Unfortunately I spotted a catch-22 situation while working on CLI
8.1.x WIP in https://github.com/apache/cordova-cli/pull/326:
* insight@0.8 (0.8.4) has the audit issue
* newer insight starting with 0.9 uses inquirer@5 which does not
support Node.js 4.
I can think of the following alternatives:
http://cordova.betamo.de/cordova-board-reports-issue-and-pr-searches.php
now exists and displays for multiple quarters (past and present) links
to GitHub searches that show:
- Issues created in quarter (displays individually how many of those
still open and how many closed)
- Issues closed in
A few issues have started to come in regarding the state of Cordova
projects on Xcode 10. This is a rough summary of the situation:
Xcode 10 uses a new build system by default (previously available on
an opt-in basis in Xcode 9). The cordova-ios project structure is not
compatible with this new
Let's get this process down right for next quarter, if we don't get it
in time for this one.
Yes, the reporting dates are in the README for tge repo for the draft report.
On Fri, Sep 14, 2018 at 7:32 PM Jan Piotrowski wrote:
>
> Thanks for pulling me in here julio.
>
>
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
Am Fr., 14. Sep. 2018 um 14:15 Uhr schrieb Chris Brody <
chris.br...@gmail.com>:
> Thanks Raphael for the reminder about insight, which I overlooked. I
> personally do not like the idea of an extra reminder message before the
> next major release. I would like to consider this over the weekend
>
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
Thanks Raphael for reviewing the PR 4 hours ago. Sorry I missed it.
On Fri, Sep 14, 2018, 8:19 AM Jan Piotrowski wrote:
> What PR needs another review? Raphael reviewed the only one you linked
> in this thread 4 hours ago.
>
> 2018-09-14 14:15 GMT+02:00 Chris Brody :
> > Thanks guys for the
What PR needs another review? Raphael reviewed the only one you linked
in this thread 4 hours ago.
2018-09-14 14:15 GMT+02:00 Chris Brody :
> Thanks guys for the feedback. I would also appreciate a review of the PR on
> GitHub (from a PMC member).
>
> Thanks Raphael for the reminder about
Thanks guys for the feedback. I would also appreciate a review of the PR on
GitHub (from a PMC member).
Thanks Raphael for the reminder about insight, which I overlooked. I
personally do not like the idea of an extra reminder message before the
next major release. I would like to consider this
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
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:
*
Thanks for pulling me in here julio.
http://cordova.betamo.de/cordova-github-issues-search-strings.php
creates the search strings for all issues on all repositories (bottom
left).
Just adding the time frame doesn't work, with `created:>2018-06-01
created:<2018-09-01` added at the end, it seems
Jan had some filters to easily see/list bugs, but not sure if it's possible
to know the number of created/closes issues by quarter.
Will put him in copy just in case he missed the draft and can chime in to
provide more information.
El vie., 14 sept. 2018 a las 2:34, Shazron () escribió:
> What
The only minor doubt I'd have is about the insight update: as I've
mentioned in the corresponding PR, it will cause _all_ users to be pompted
again about their telemetry preference. I've thought that to be OK for a
major release. Might be a bit strange in a minor though. Just wanted to let
you
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
28 matches
Mail list logo