Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Add a published .d.ts diff to the release process to catch breaking type changes

Open
  • Is something wrong?
#749 4 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
55/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
typescript
Domain
ci-cd, release

Research direction

Start with the repository's existing release or CI process and use npm pack to compare the latest published package with the release candidate. Extract dist/*.d.ts, identify non-additive type changes, and make the check fail or require an explicit breaking acknowledgment with an appropriate version bump.

Written by the indexing model from the issue text.

Description

Problem

4.2.4 shipped as a patch but contained breaking TypeScript type changes with no changelog note. The main one: ObservableStatus<T> was refactored from a flat interface (data: T) into a discriminated union (data: T | undefined unless narrowed on status), which breaks the standard destructure-and-use pattern across every data hook, including the documented suspense pattern. It is type-only (no runtime impact), but it reds strict-TS consumer CI on upgrade.

It slipped through because:

  • The change came in via #583 ("use useSyncExternalStore to sync data"), whose title looked like an internals change, not a public API break.
  • It then sat unreleased for ~3 years (v4.2.3 was 2022-08, #583 merged 2023-07).
  • 4.2.4 batched 35 PRs of accumulated main into one bump, with no step auditing the cumulative public type surface.

Proposal

Add a release-time (or CI) check that diffs the candidate's emitted types against the last published version:

  1. npm pack the latest published version, extract dist/*.d.ts.
  2. npm pack the release candidate, extract dist/*.d.ts.
  3. Diff them. Any non-additive change (removed/narrowed/changed signature) fails the check or requires an explicit "breaking" acknowledgment and a minor/major bump.

This exact diff would have flagged both the ObservableStatus union change and the useFirestoreDocData widening (#733) immediately.

Related

  • Remediation for the live 4.2.4 release is tracked separately (deprecate + re-cut as 4.3.0 with a migration note).
  • Surfaced while reviewing #740.
Dominant language
TypeScript
Stars
3.6k
Forks
403
Avg merge
4d 19h
Merged PRs (30d)
11

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from FirebaseExtended/reactfire

All issues in FirebaseExtended/reactfire

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.