Stop setting issue due dates that are already in the past

[srubin]

What's wrong

When a dependency blows past its SLA threshold before Dependicus ever files an issue, the calculated due date (first required version's publish date + thresholdDays) lands in the past. The issue was then created already overdue, e.g. Update temporalio from 1.3.0 to at least 1.4.0 (due 2024-05-06) filed in 2026. Fixes BIX-8427.

What changed

• New isDueDateInPast(dueDate, now?) helper in src/core/utils/versionUtils.ts, exported from @dependicus/core. It compares by calendar day in UTC — the same way due dates are serialized onto issues — so a due date of today still counts as upcoming.
• Both reconcilers now run the calculated due date through a small resolveDueDate helper before writing it:
  • Creating or reopening an issue with a due date that has already passed: no due date is set. On Linear that means the due date field is left empty; on GitHub it means no (due YYYY-MM-DD) suffix in the title and no due date row in the body. The issue still reports how many days overdue the dependency is.
  • Updating an existing issue: a due date the issue already carries is preserved rather than cleared once it passes. Without this, every issue would lose its due date the day after the deadline, and Linear would stop showing it as overdue. Linear reads the existing value from the issue's due date field; GitHub reads it back from the (due …) suffix on the existing title, so titles and bodies stay stable and no needless updates are pushed.
  • FYI/notification-only dependencies are unaffected — they still get no due date.
• Docs: added a "Due dates" section to the Linear issues page and extended the GitHub issues one.

Testing

New tests cover the helper plus both reconcilers (creation, update-preserves-existing, update-doesn't-add-past-date, and a still-upcoming due date that is set as before). I confirmed all five new reconciler assertions fail when the past-date check is neutered. Full suite: 921 passing, plus lint, format, and typecheck clean.

Beyond unit tests, I ran the real CLI in --dry-run mode against this repo's own dependency data, once against a build of main and once against this branch. Two dependencies are genuinely past their thresholds, and main files them with due dates that had already passed:

Note on #95

This supersedes #95, which took the same "drop the date if it's in the past" approach but folded it into calculateDueDate itself. That variant also wiped the due date off every existing issue the moment its deadline passed, since the reconcilers pass undefined straight through as an explicit null on update. This PR keeps calculateDueDate a pure calculation and applies the policy at the point of writing, so already-set deadlines survive.

Our dependency deadlines were flying south for the winter and never coming back; they're staying put now, and no goose gets a due date it has already waddled past. 🦆

Linear Issue: BIX-8427

  

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 0962790. Configure here.}

[cursor]

Past due dates break GitHub matching

Medium Severity

Once a calculated due date has passed, resolveDueDate drops the (due …) suffix because there is no open issue title to read it back from. GitHub reopen and PR dedup both require an exact title match, so a closed issue or ready-for-review PR that still has the suffix is missed and a duplicate issue is created.

Additional Locations (2)

• src/github-issues/issueReconciler.ts#L710-L728
• src/github-issues/issueReconciler.ts#L818-L826

 

^{Reviewed by Cursor Bugbot for commit 0962790. Configure here.}