default.json

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "description": "Shared Renovate preset for digitalnsw repos. Consumer repos extend this via the synced renovate.json (source: repo-files/renovate.json). Edit HERE; Renovate reads it from main at run time, so changes apply everywhere without a sync.",
  "extends": ["config:recommended", ":semanticCommits", "group:allNonMajor"],
  "timezone": "Australia/Sydney",
  "schedule": ["before 7am on monday"],
  "prConcurrentLimit": 5,
  "labels": ["dependencies"],
  "gitIgnoredAuthors": ["41898282+github-actions[bot]@users.noreply.github.com"],
  "vulnerabilityAlerts": {
    "enabled": false,
    "description": "Security alerting/fix PRs stay with Snyk — avoids duplicate PRs for the same CVE."
  },
  "lockFileMaintenance": {
    "enabled": true,
    "schedule": ["before 7am on the first day of the month"],
    "description": "Monthly full lockfile regeneration with real npm — keeps lockfiles fresh and valid."
  },
  "packageRules": [
    {
      "description": "npm majors are blocked everywhere they appear (engines, overrides, devDependencies) until the platform bundles the new major. engine-strict=true means pulling in npm ahead of the Vercel/CI bundled npm fails every install with EBADENGINE (see nswds-email#460 — npm 12 needs Node ^22.22.2 || ^24.15.0, expected bundled with Node 26 ~Oct 2026). Remove this rule as part of the coordinated adoption pass (reusable-ci + engines.node floor + lockfile regen, same shape as nswds-email#458).",
      "matchPackageNames": ["npm"],
      "matchUpdateTypes": ["major"],
      "enabled": false
    },
    {
      "description": "Renovate updates to override-pinned packages are disabled at every update type, because two independent failure modes both end in a lockfile that fails npm ci fleet-wide. (1) In-range lockfile-only bumps: Renovate applies them via `npm install <pkg>@<version>`, which adds the package as a direct dependency whose spec conflicts with the override, so npm aborts with EOVERRIDE and the whole grouped PR ships a stale lockfile (nswds-email#459, fast-uri). (2) Range bumps: Renovate rewrites package.json but only half-applies the lockfile — it removes the outgoing entry and never adds the resolved one — so npm ci dies with EUSAGE `Missing: <pkg>@<version> from lock file`. This one is the more dangerous of the two: Renovate posts no artifact-update warning, so the PR looks healthy, and the checks that stay green (Vercel runs `npm install`, which silently repairs it) read as evidence that it isn't (nswds-email#485, postcss-selector-parser ^6.1.3 → ^7.0.0, which took out install, lint, commitlint and editorial). Scoped pins are covered too — Renovate's extractOverrideDepsRec sets depType `overrides` at every nesting level, so `{\"@tailwindcss/typography\": {\"postcss-selector-parser\": \"^7.0.0\"}}` matches this rule. What is given up: the pinned ranges no longer get automatic bump PRs. Monthly lockFileMaintenance still refreshes the resolved version inside each range, and the ranges themselves are vulnerability pins that Snyk already owns (vulnerabilityAlerts is disabled for the same reason) — so raise them by hand off a Snyk finding, the way nswds-email#484 was. Remove this rule when Renovate's npm manager writes correct lockfiles for overrides.",
      "matchDepTypes": ["overrides"],
      "enabled": false
    },
    {
      "description": "conventional-changelog-conventionalcommits v10 is blocked: preset v10's render-function templates are incompatible with @semantic-release/release-notes-generator@14 — commit analysis still computes correct release types, but generateNotes silently emits an empty changelog body (reproduced with the shared release.config.mjs; tracked upstream as issue #992). v10 also arrives transitively: @commitlint/config-conventional 21.2.0 bumped its ccc dependency from ^9.2.0 to ^10.0.0 and the hoisted copy is what the preset loader finds — this blanked nswds-email changelogs 1.140.5–1.140.12 (nswds-email#437) and, until the 2026-07-19 fleet rollout, every release of nswds-devops and digitalnsw (whose direct pin was on the wrong major, ^10.2.0) plus the newest releases of data, nswds-signature, nswds-community and nswds-email-issues. All 16 semantic-release repos now carry a direct ^9.3.1 devDependency pin — the root hoist resolves v9 for the preset loader while commitlint nests its own v10 — and this rule stops Renovate from majoring those pins back to v10. When a release-notes-generator release compatible with ccc v10 ships, remove this rule and bump the 16 pins together.",
      "matchPackageNames": ["conventional-changelog-conventionalcommits"],
      "matchUpdateTypes": ["major"],
      "enabled": false
    },
    {
      "description": "typescript majors (6/7) are blocked: the typescript@7 npm package is the native Go compiler and require('typescript') exposes no JS compiler API, so `next build` fails (Next 16.2.x: 'required package(s) not installed', broke CI and Vercel deploy), eslint crashes via @typescript-eslint/typescript-estree (peer range >=4.8.4 <6.1.0), and prettier-plugin-organize-imports silently no-ops — imports stop being sorted while format hooks keep passing (see nswds-email#444; reproduced 2026-07-18). Native `tsc -b` itself works. Remove when Next.js and typescript-eslint declare TS 6/7 support.",
      "matchPackageNames": ["typescript"],
      "matchUpdateTypes": ["major"],
      "enabled": false
    },
    {
      "description": "eslint + @eslint/js majors are blocked, and the two MUST move in lockstep: @eslint/js@10 declares peerDependencies { eslint: ^10.0.0 } (v9 declared none), so bumping @eslint/js alone leaves eslint at ^9 and yields an unsatisfiable graph — Renovate cannot regenerate the lockfile (ERESOLVE) and every npm ci fails (EUSAGE). This matcher previously listed only \"eslint\", which let the eslint-monorepo group split the pair and broke nswds-tokens#132 (superseded by the combined bump in nswds-tokens#140). The block itself stays because ESLint 10 removed context.getFilename(), which eslint-plugin-react 7.37.5 (pulled in transitively by eslint-config-next, incl. 16.2.11) still calls in its React-version detection path — every eslint invocation then crashes with a TypeError before linting a single file (reproduced on nswds-app#418 and locally against eslint-config-next@16.2.11 + eslint@10; upstream jsx-eslint/eslint-plugin-react#3977, vercel/next.js#89764). PR CI does not run lint, so the breakage would merge green and only surface in local dev. The crash is confined to config-next consumers: repos with no eslint-plugin-react in the tree (e.g. nswds-tokens) are unaffected, and the Next.js repos can unblock now by wrapping the config-next presets in @eslint/compat's fixupConfigRules — the pattern already shipping in nswds-email (eslint@10, eslint-config-next@16.2.11). Remove this rule once the Next.js repos adopt that shim (or eslint-config-next ships an ESLint-10-compatible eslint-plugin-react — watch vercel/next.js#89764), and re-check the other capped peers (eslint-plugin-import, eslint-plugin-jsx-a11y) at the same time.",
      "matchPackageNames": ["eslint", "@eslint/js"],
      "matchUpdateTypes": ["major"],
      "enabled": false
    },
    {
      "description": "0.x minors are split out of the all-non-major group into their own PRs. Under SemVer a 0.x release carries no compatibility guarantee — 0.a.b -> 0.c.d may break freely — but Renovate still classifies that bump as `minor`, so `group:allNonMajor` batches it with genuinely safe updates. That is how @figma/rest-api-spec 0.33.0 -> 0.41.0 rode into nswds-tokens#130 behind 45 other bumps: 0.35.0 widened VariableValue to include null, `typeof null === 'object'` broke narrowing in compareVariableValues, and `npm run typecheck` failed — a review-time catch that a 400-line lockfile diff invites you to skim past. Ungrouping gives each 0.x minor its own PR, its own diff, and its own release notes to read. 0.x patches stay grouped: they remain bug-fix-only by convention and are the bulk of the volume.",
      "matchPackageNames": ["*"],
      "matchCurrentVersion": "<1.0.0",
      "matchUpdateTypes": ["minor"],
      "groupName": null,
      "groupSlug": null
    }
  ]
}