scratch-renovate-config

Scratch's shared configuration files for Renovate

While Renovate supports JSON5 in some contexts, the configuration files in this repository are in strict JSON format. See renovatebot/renovate#7674 for more information.

Available configurations

Use the extends array within your Renovate configuration file to extend one of these configurations. For example: extends: ["github>scratch-renovate-config"]

Name	File
github>scratchfoundation/scratch-renovate-config:base	base.json
github>scratchfoundation/scratch-renovate-config	default.json
github>scratchfoundation/scratch-renovate-config:js-lib	js-lib.json
github>scratchfoundation/scratch-renovate-config:js-lib-bundled	js-lib-bundled.json
github>scratchfoundation/scratch-renovate-config:js-app	js-app.json
github>scratchfoundation/scratch-renovate-config:conservative	conservative.json

base.json

This applies basic configuration without any automatic merge rules. It's intended to be used by the other configurations in this repository, not by itself.

This extends config:best-practices, which provides (among other things):

• semantic commit rules (fix for dependencies, chore for devDependencies)
• pin devDependencies to exact versions
• weekly lock file maintenance

On top of that, base.json adds:

• set time zone to Scratch time (America/New_York)
• remove concurrent PR limit
• require 3 days of minimumReleaseAge before automatically merging external dependencies
  • this configuration does not enable automatic merges but does preconfigure this setting
• label all Renovate PRs with dependencies
  • add the security label for any PR associated with a GitHub Security Vulnerability
• separate major updates from minor/patch updates: if both are available, open two separate PRs
• identify internal dependencies by source URL and give them higher priority, exempt them from minimumReleaseAge, and adjust semantic commit types so that internal dependency bumps trigger appropriate version bumps downstream

Note: matchSourceUrls patterns use only https:// URLs because Renovate normalizes all source URLs (including git+ssh://, git://, git@host:, etc.) to https:// before matching.

default.json

This enables automatic merging of minor and patch releases. External dependencies are subject to the minimumReleaseAge setting from base.json. This can be used directly, but the js-lib and js-app configurations may be more appropriate.

js-*.json

These build on the default.json configuration and add pinning according to Renovate's dependency pinning recommendations. Since devDependencies are already pinned by config:best-practices (via base.json), js-app additionally pins production dependencies. js-lib does not add any extra pinning beyond what base.json provides. These are intended to be the Scratch versions of Renovate's built-in config:js-lib and config:js-app presets.

The js-lib-bundled configuration is a variant of js-lib designed for libraries that use a bundler (webpack, etc.) to build their npm package. It treats lockFileMaintenance PRs as fix instead of chore. For rationale, see the "About Pinning" section below.

conservative.json

This legacy configuration enables automatic merging of major and minor releases for only internal dependencies.

About Pinning

See Renovate's documentation for more information.

All configurations pin devDependencies to exact versions (via config:best-practices in base.json). The js-app configuration additionally pins production dependencies.

Together, this means that non-dev dependencies of libraries are pinned at the app level only.

More specifically, suppose scratch-vm uses a library foo as a dependency (not devDependency), and foo updates from 1.0.0 to 1.1.0. Suppose neither scratch-gui nor scratch-www use foo as a direct dependency.

1. scratch-vm, where foo is listed as ^1.0.0, will receive a lockFileMaintenance PR to update foo.
   • For a "normal" npm module, this PR would be unable to affect user-visible behavior, because it will not affect package.json or any other file.
   • Since scratch-vm uses webpack, dependencies like foo are likely to be included in the build output, thus this PR could cause user-visible behavior changes.
     • If scratch-vm's build output is used by an app, then scratch-vm's lockFileMaintenance PR could cause user-visible behavior changes in that app, implying that this should cause a scratch-vm release.
     • If the app uses scratch-vm's source instead of its build output, then scratch-vm's lockFileMaintenance PR cannot cause user-visible behavior changes in the app, implying that this should not cause a scratch-vm release.
2. scratch-www will also receive a lockFileMaintenance PR to update foo.
   • foo is not listed in scratch-www's package.json, so this PR won't affect that file.
   • If scratch-www uses scratch-vm's build output, then scratch-www's lockFileMaintenance PR will not cause user-visible behavior changes in scratch-www. The app would receive any user-facing impact from the foo update when scratch-www updates its scratch-vm dependency.
   • If scratch-www uses scratch-vm's source, then scratch-www's lockFileMaintenance PR will cause user-visible behavior changes in scratch-www. The app could receive some user-facing impact from the foo update here and some from the scratch-vm update, or only one or the other.

In other words, by using webpack (or any bundler) at the library level, we have made it difficult to predict the effects of a lockFileMaintenance PR and blurred the meaning of dependencies vs. devDependencies. Ideally, we should use webpack only at the app level; combined with Renovate's pinning recommendations, this would mean that library lockFileMaintenance changes could never affect user-visible behavior at the app level. Only app lockFileMaintenance changes could affect user-visible behavior. For now, marking lockFileMaintenance PRs as fix seems the safest option.

Contributing

Before submitting a pull request, please validate your changes:

npx --package=renovate@latest renovate-config-validator *.json