[Baseline practices] Keeping dependencies and node up to date

We should have a doc, which describes the whys and the hows of staying up to date.

Something like the steps involved in setting up renovate bot on github for a repo and what are views are on the sort of schedule for updates?

Yes, although I think we should cover more than just renovate. There's also options for automerging, lock file maintenance, etc.

One thing I'd also be interested to see is keeping multiple release lines updated, esp. If we're going to make LTS for packages happen.

FWIW

@bevry accomplishes the goal of this automatically for all of its packages, through the following pieces

https://github.com/bevry/boundation enforces consistency against packages, including support for all the below, and including support for local testing on the package's specified node versions via https://github.com/bevry/testen
- https://github.com/bevry/editions enables support for older node versions, as well as provides standardised data about the environments the package supports and what technology it uses
- https://github.com/bevry/projectz enforces consistency of the meta files, such as the readme and package.json, and installation and license information, including badge information via https://github.com/bevry/badges
- https://github.com/bevry/awesome-travis has several scripts such as
  - https://github.com/bevry/awesome-travis/blob/master/scripts/surge.bash which publishes the commit, branch, and tag to surge for browsing of docs and cdn
  - https://github.com/bevry/awesome-travis/blob/master/scripts/node-publish.bash publishes git tags to latest and master (as configured by NPM_BRANCH_TAG) to the next tag
  - https://github.com/bevry/awesome-travis/blob/master/scripts/node-install.bash ensures dev deps are installed with the desired node version, to enable tests to run even on legacy node versions
- dependabot configuration to auto-merge passing dependency updates
https://github.com/balupton/dotfiles/blob/master/.scripts/users/balupton/commands/boundation-upgrade runs boundation on a project, and publishes a new release - if the engines changed, publishes a new major release, otherwise a minor
https://github.com/balupton/dotfiles/blob/master/.scripts/users/balupton/commands/boundation-all runs boundation-upgrade on all bevry's packages

tools.md: add bevry's automation tooling

@ljharb

Adding to the meeting agenda:

I think we need an official repo (i.e. under nodejs, not pkgjs org) for Travis (and in the future - other CI setup?) includes. I know @ljharb was working on something - not sure how ready that is?

What I'd like to see is an include file with min version and the support policy - we can discuss details in the meeting/new issue (in the new repo?)

I have https://github.com/ljharb/travis-ci which I’m using in hundreds of repos; there’s parts of it that remain mildly opinionated about package.json scripts structure, is all.

That said, it’s already possible to rely on just the version matrix from it.

Is the reason this is travis specific because that is still the most popular? I personally am switching everything to GH actions, and we discussed on Express doing the same. It seems like having one project with shared configurations just for the node versions part for all popular CI services would be the right course no?

EDIT:

and in the future - other CI setup?

I see you agree that it should include other CI services, my bad. With that as the goal I agree!

I don’t think there can be a single universal source based on what’s supported right now; i think each service needs it’s own distinct solution (even if that’s all maintained by us).

GH actions

TBH, I haven't followed the latest developments, but I was hoping that it can all be done natively by GH... If that's not available - sure, absolutely, we should provide an official recommendation in the nodejs org.

I think a repo-per-service is probably better? Ideas for a naming convention?

I recently setup dependabot on a few repos to see how it works. My first take is "WOW it is so chatty". We had disabled it on Express for this reason, and I thought maybe there were just some settings to make it better. I could not find those settings.

Here are the questions I have:

Why it closes and re-opens new PRs for the same dependency as it continues to get updated? Seems like it should just force push to the same PR.
Can it have one PR with many commits which update each the out of date deps. That would centralize it and also make it so you could cherry pick out the ones you want.
Can it allow repos to specify rules around which deps to update. In Express packages there are many deps we would want it to ignore for specific reasons. If we dont have this I am not sure we can use it.

They have a feedback repo, so maybe I will reach out to them there.

I definitely disable dependabot on every repo for these reasons and others; i prefer greenkeeper.

Chiming in here since I actually wrote about this thing recently with regards to Snyk which recently rolled out support for dep upgrades.

One of the key points I was making is the ability to configure the type of upgrades you want to receive, ignore some packages if you want, and most importantly the default setup limits the PRs being opened to 5 exactly due to the problem of increased noise and overhead in managing a repo for devs:

Here are the questions I have:

I know for sure that renovate can do all of these things.

I definitely disable dependabot on every repo for these reasons and others; i prefer greenkeeper.

Greenkeeper is being sunset on 3rd June 2020: https://greenkeeper.io/

… and replaced with a Snyk service.

For those looking to replace Greenkeeper, this Renovate config comes pretty close:

{
  "extends": ["config:base"],
  "labels": ["greenkeeper"], // ;)
  "suppressNotifications": ["prIgnoreNotification"],
  "rangeStrategy": "replace"
}

Navigation Menu

Repository navigation

[Baseline practices] Keeping dependencies and node up to date #280

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Baseline practices] Keeping dependencies and node up to date #280

Description

Activity

ghinks commented on Nov 9, 2019

dominykas commented on Nov 9, 2019

balupton commented on Nov 18, 2019

dominykas commented on Feb 17, 2020

ljharb commented on Feb 17, 2020

wesleytodd commented on Feb 17, 2020

ljharb commented on Feb 17, 2020

dominykas commented on Feb 17, 2020

wesleytodd commented on Feb 20, 2020

ljharb commented on Feb 20, 2020

lirantal commented on Feb 20, 2020

dominykas commented on Feb 23, 2020

richardlau commented on Apr 6, 2020

ljharb commented on Apr 7, 2020

vweevers commented on Apr 7, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions