[belaboe]

Problem

The weekly ncu job (ncu -u --target minor) raises the minimum version in each package.json range when it bumps a dependency, for example ^3.2.0 → ^3.3.1. Dependabot's default strategy (auto) decides per project whether to raise or widen the range, so it doesn't always do the same. To replace the ncu job with Dependabot, the two should write the same ranges.

Issue #, if available: none

Changes

• npm entry in .github/dependabot.yml: versioning-strategy: increase ("always increase the minimum version requirement to match the new version", docs).
• Header comment updated.

This applies to the root and all workspace packages, as ncu --root --workspaces does today.

This is one of several small dependabot.yml PRs that together cover what the ncu job does, so it can be retired.

Validation

• YAML parses; the npm entry has versioning-strategy: increase.
• Config only, no published package changed, so no changeset is required (same as chore(repo): set Dependabot's default 3-day cooldown explicitly #869).

Checklist

• PR description included
• Tests are changed or added (config only)
• Relevant documentation is changed or added (header comment in dependabot.yml)

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 022f54a

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[osama-rizk]

This PR sets versioning-strategy: increase on the npm Dependabot entry, so Dependabot raises package.json floors the same way the weekly ncu job does. It's safe to merge. I checked that it doesn't change behaviour today: auto already resolves to increase for this repo, so the PR pins that and stops it from flipping to widen later. One minor comment-wording item. The open questions below are about the ncu retirement as a whole, not this diff.

Dimensions

• Correctness: good. The YAML parses, the key is on the npm entry, and increase is a valid npm value.
• Contract/compatibility: minor. Published floors keep rising on every bump, as they do with ncu today. Peer ranges aren't touched (verified in dependabot-core's npm parser).
• Tests: n/a. Config only, and the repo has no harness for Dependabot config.
• Systemic/ops: minor. Manifest edits under packages/* trigger the required "Require changeset" check (see Q1). That's already true, not new here.

What's good

• Being explicit beats relying on Dependabot's app-vs-library guess, which depends on the root package.json having no description.
• Parity with ncu -u --target minor holds on both ranges and dependency sections (prod/dev/optional; neither tool touches peer).
• Small, single-purpose PR with a header comment that explains the setting.

What needs work: 1 minor; details inline.

Open questions

1. Changesets after ncu is retired: every Dependabot PR that edits packages/*/package.json fails the required "Require changeset" check (#833 did, and so did the ncu PR #751). That includes devDependency-only bumps, which don't change anything consumers get. Who adds the changeset: a maintainer by hand, a workflow, or a guard exemption for devDependency-only manifest diffs? Since this series replaces ncu, it would help to decide that in one of these PRs.
2. increase vs increase-if-necessary for published packages: increase raises consumers' minimums on every bump (for example @aws-sdk/* clients from ^3.700.0 to ^3.1150.0), which can force upgrades or duplicate SDK copies in apps that pin older versions. increase-if-necessary keeps ranges wide and still moves the lockfile, but then CI never tests the declared floor. Parity with ncu argues for increase. Is that the deliberate choice for published dependencies too?
3. Peer floors (aws-cdk-lib ^2.257.0, constructs) stay manual while the devDependency copies keep rising, so code can start using newer CDK APIs without the peer floor moving. Is there a plan or an owner for keeping peer floors honest?

Cross-cutting

• versioning-strategy applies per update entry. With a single / entry you can't use different strategies for production and dev dependencies, so any split from Q2 would need a different shape.

[osama-rizk]

Non-blocking (minor): The comment is accurate about increase, but two things a future reader needs are missing, and one bit is misleading.

1. "not only the lockfile" suggests the previous behaviour was lockfile-only. It wasn't. With auto, Dependabot treats the root package.json as an app, not a library: it has a version, no description, and isn't private, and dependabot-core's library detector needs a description that matches the registry entry. For an app, auto resolves to increase. You can see this in the Dependabot commit on chore(deps): bump the aws-sdk group across 1 directory with 24 updates #816, which raised @aws-sdk/client-bedrock from ^3.700.0 to ^3.1150.0 even though 3.1150.0 was already in range. So this line pins today's behaviour; it doesn't change it. That's still worth doing: adding a root description or a lerna.json would otherwise flip it silently to widen.
2. Dependabot never edits peerDependencies. Its npm parser only reads dependencies, devDependencies and optionalDependencies. So the aws-cdk-lib/constructs peer floors stay hand-managed. That matches ncu, whose default --dep also leaves out peer, but it's the contract fact people will ask about for published packages.

Fix: reword the bullet so it says this matches ncu, pins what auto already resolves to, and leaves peer ranges alone.

Suggested change

	# - versioning-strategy: increase raises the minimum version in package.json
	# to the new release (^3.2.0 -> ^3.3.1), not only the lockfile.
	# - versioning-strategy: increase raises the minimum in package.json to the
	# new release (^3.2.0 -> ^3.3.1), matching ncu. It pins what "auto" already
	# resolves to here (the root package.json is not detected as a library).
	# peerDependencies are never edited: aws-cdk-lib/constructs floors stay manual.

[belaboe]

Fixed in #992 (93c5cac), along your suggestion. The peer wording is a little narrower than "never edited": package_json_updater.rb rewrites a peer range identical to the one it bumps (none here today).

[belaboe]

@osama-rizk follow-ups on the review summary:

• Q1, changesets: covered by ci(release): write the changeset for Dependabot bumps at release time #977, which writes them at release time.
• Q2: the maintainers keep increase, as ncu does.
• Q3, peer floors: chore(repo): review fixes for #874: versioning-strategy comment #992's description carries the proposed text for this PR, with "Owner: (to be named by maintainers)".

[osama-rizk]

Since the last review: 1 resolved · 0 new · 0 still open

Approving. This PR only pins versioning-strategy: increase on the npm Dependabot entry. That matches what auto already resolves to here, so behaviour doesn't change today, and the setting stops it flipping to widen later.

Resolved

• .github/dependabot.yml:16-17 header wording: fixed in #992 (commit 93c5cac). The bullet now says the setting does what the ncu (npm-check-updates) job does, pins what auto already resolves to, and leaves the aws-cdk-lib/constructs peer floors manual. Your narrower peer wording is right. package_json_updater.rb also rewrites a peerDependencies declaration that is identical to the one it bumps, so "doesn't read peerDependencies (only rewrites an identical peer range)" is more accurate than my "never edited". No package has such a pair today.

What I verified on head c523f42

• The YAML (YAML Ain't Markup Language) parses with js-yaml, and updates[0]["versioning-strategy"] is increase.
• On current main and on the merge base, the root package.json still has no description and there's no lerna.json, so auto would still resolve to increase. The pin changes nothing today.
• The branch merges cleanly into current main.

Answers to the open questions (thanks)

• Q1, changesets on Dependabot PRs: #977 handles it. The guard lets Dependabot PRs that only touch manifests through, and the release job writes the changeset.
• Q2: increase stays, as the maintainers decided.
• Q3, peer floors: they stay manual, and #992 drafts the description text. The owner is still to be named.

Follow-ups (not blocking)

• Merge order: the wording fix lives in #992, which is stacked on this branch. Merge #874 first, then #992, retargeted to main if GitHub doesn't do that itself. It would be worth adding the "Text for #874's description" block from #992 to this description before merging.
• The one red check, Require changeset, comes from the 2026-10-19 run. It's a teardown flake in scripts/changeset-guard.test.mjs:555 (ENOTEMPTY while removing a temp .git directory) and has nothing to do with this config-only diff. A re-run should clear it.
• Q3 still needs an owner for the peer floors.