@ChristianMurphy The types/node update has no effect whatsoever. Can we do without such changes?

This is the base configuration, the description of what that entails is above.
A couple notable tweaks that other projects have made: scheduling PRs to reduce noise and not pinning dev dependencies also to reduce noise

The types/node update has no effect whatsoever. Can we do without such changes?

They can impact typescript validation.
Packages and/or groups of packages can be disabled, but there are a lot of noise reducation techniques which could also be explored https://docs.renovatebot.com/noise-reduction

It could, but it shouldn't according to semver tho?

Re noise reduction: I'm up for all of those mechanisms 😅

It could, but it shouldn't according to semver tho?

Sometimes.
Like most libraries, if part of it is exported in the public API, yes, it falls under SemVer.
If it's used for internal validation only, it isn't necessarily covered by SemVer.

In the case of VSCode plugins, I don't thing the types are part of the public API.

It’s a dev-dep here: so it shouldn’t be exposed in any way. I get what you mean if it were a direct dep though

Is this good to go?

Renovate is disabled

Renovate is disabled because there is no Renovate configuration file. To enable Renovate, you can either (a) change this PR's title to get a new onboarding PR, and merge the new onboarding PR, or (b) create a Renovate config file, and commit that file to your base branch.

I can see that renovate.json was removed by @remcohaszing in #108, without any clear explanation of why other than "we don't really use it". Is it a Unified policy to not keep packages up to date, or that it needs to be a manual task or something else? @ChristianMurphy @wooorm

It is unified convention to use wide version ranges so that updates happen largely automatically, without need for a bot.
When the updates happen, they generally happen in batches with major version changes which require manual intervention anyway.

I see. That makes sense for NPM packages, but what about GitHub Actions and such? I would still like #90 and #91 to be submitted automatically.

Actions don’t change frequently, and like other dev-dependencies, it is less important to update right when new majors are released.

Sure, but I don't manually follow up on when all of the GitHub Actions in all of my repositories release a new version. I expect a tool to convey that information to me, without me having to lift a finger. How can we achieve that?

I don’t think we need to achieve that.
Renovate wasn‘t used here and it was noisy.

Renovate was absolutely used and many of its pull requests were merged. I’ll leave it to you to keep all dependencies up to date, then.