[polylane]

Every weekly Backstage version-bump run failed its typecheck, so the automated upgrade pull request stayed a draft and could not be reviewed. The failure came from how the upgraded dependency set resolved one date library. After this merges, the bump run typechecks cleanly and its pull request can be marked ready.

flowchart TD
  A["versions:bump upgrades @backstage/ui to 0.19.0"] --> B["react-aria 3.53.1 / react-stately 3.51.0 require @internationalized/date ^3.12.4"]
  A --> C["@backstage/ui 0.19.0 requires @internationalized/date ^3.12.0"]
  B --> D["nested copy 3.12.4 installed"]
  C --> E["hoisted copy 3.12.2 installed"]
  D --> F["TS2344: CalendarDate is not assignable to react-stately DateValue"]
  E --> F
  F --> G["validate typecheck job fails; draft PR stays a draft"]
  H["Fix: resolutions @internationalized/date ^3.12.4"] -.->|"dedupes to one copy"| F

Loading

Detection evidence

Affected: int_17ad4b457001o98datdn4tkm

Why this fix

The bump branch installs two versions of @internationalized/date: @backstage/ui 0.19.0 needs ^3.12.0, while the react-aria and react-stately versions it pulls in need ^3.12.4. With two copies, the date value types are nominally different and @backstage/ui's date picker types do not compile. Forcing a single version through the existing resolutions block removes the duplicate. I reproduced the failure on the bump tree and confirmed the typecheck then passed, and that on main the install stays immutable and the typecheck is clean. The remaining risk is a future bump that needs a newer major, when the range must move with it.

Production impact: Dependency dedupe changes no production resource behavior

I checked the datum-cloud/backstage repository; the infrastructure graph records no deployed resource for it, so this change reaches only the build. The bump dependency set drops from two @internationalized/date copies to one, and the main install with yarn install --immutable and yarn tsc:full passes.

Checked and not affected: provider#code#account#datum-cloud#region#earth#type#code.repository#id#datum-cloud/backstage.

Observability

• The typecheck job in the validate reusable workflow: the signal this change corrects.
• No new log or metric is added; the existing CI result is the signal.

Polylane assessed this pull request at 75505b1.

Fix walkthrough

Watch the fix explained (1:25). Recorded for commit 75505b16fc18247d9c5bfd7dadda4b43210fe969.

Causal chain

• Signal (log template): error TS2344: Type 'DateValue' does not satisfy the constraint 'react-stately ... DateValue' in node_modules/@backstage/ui/dist/index.d.ts
• Surfacing site: datum-cloud/backstage (Actions workflow Backstage Version Bump) at datum-cloud/backstage:.github/workflows/version-bump.yaml#validate -> .github/workflows/ci.yaml#typecheck
• Mechanism: The bumped dependency tree installs two @internationalized/date versions (hoisted 3.12.2 for @backstage/ui's ^3.12.0 requirement, nested 3.12.4 for react-aria/react-stately's ^3.12.4 requirement). The DateValue interface in each copy is nominally distinct, so @backstage/ui's DatePickerProps/DateRangePickerProps constraint raises TS2344.
• Producer: yarn dependency resolution in datum-cloud/backstage, at datum-cloud/backstage:package.json#resolutions
• Cadence check: Weekly scheduled cron; failing on each of the 2026-10-12, 10-19 and 10-26 runs per the finding.
• Blast radius: unknown other resource(s), unknown other tenant(s); data at risk: none named
• Producer evidence:
  • Bump branch yarn.lock (75493e6) carries two @internationalized/date resolutions, 3.12.2 and 3.12.4.
  • Sandbox reproducer: nested 3.12.4 under react-aria/react-stately/react-aria-components plus hoisted 3.12.2, and yarn tsc:full printed the two TS2344 errors.
  • After a single resolutions entry, one copy 3.12.4 remained and yarn tsc:full exited 0.

2 files changed (+6/-5)

• package.json: modified, +2/-1
• yarn.lock: modified, +4/-4

---

Generated by Polylane. You can ask follow-ups by mentioning @polylane in a comment.

[ecv]

Approve.

Lockfile-and-resolutions change only, as claimed: one new resolutions entry plus the matching yarn.lock collapse of three ranges into a single 3.12.4 entry. Typecheck, test, lint, kind-e2e and Trivy are green at 75505b1.

• ^3.12.4 satisfies every dependent range (^3.12.0, ^3.12.1, ^3.12.2, and react-aria/react-stately at ^3.12.4); same major, 3.12.4 is the current latest on npm.
• It does not hold anything off a fix: it is a floor, so later 3.x releases are still allowed, and the lock moves forward from 3.12.2, not back.
• The new entry sits after the uuid ones in package.json and is not grouped with them; harmless.

Follow-ups:

• The resolution is permanent. Once react-aria and @backstage/ui both require ^3.12.4 or newer naturally, drop it so it cannot mask a future major bump.