Skip to content

TypeScript guidelines: Add Derive types from authoritative sources guideline - #178

Open
MajorLift wants to merge 4 commits into
mainfrom
jongsun/typescript/derive-from-authoritative-types
Open

TypeScript guidelines: Add Derive types from authoritative sources guideline#178
MajorLift wants to merge 4 commits into
mainfrom
jongsun/typescript/derive-from-authoritative-types

Conversation

@MajorLift

@MajorLift MajorLift commented Jul 16, 2026

Copy link
Copy Markdown
Contributor

Adds a Derive types from authoritative sources instead of re-declaring them subsection to the Type Inference section.

The section already covers preferring inference for values and avoiding accidental widening, but not the common case (especially with AI) of hand-writing a type that restates one an authoritative source already defines.

Includes counterexamples.


Note

Low Risk
Documentation-only change to internal TypeScript guidelines; no runtime or build behavior.

Overview
Adds a Type Inference subsection, Derive types from authoritative sources instead of re-declaring them, to docs/typescript.md. It tells contributors to use indexed access, typeof, ReturnType/Parameters, and Pick/Omit/Partial instead of hand-written types that duplicate controller state, package exports, or other canonical shapes.

The text covers duplication, overly wide or narrow restatements (including dropped | undefined and “dead” guards), drift when the source changes, and extra risk at JS/any boundaries where restated parameter types are never checked. Two 🚫/✅ examples show Record<string, unknown> and casts vs TokenListState, and a JS caller with StorageShape | undefined vs a narrowed parameter that invites removing a default.

A small formatting tweak adds a blank line before a bullet under Avoid any.

Reviewed by Cursor Bugbot for commit b87151f. Bugbot is set up for automated code reviews on this repo. Configure here.

@MajorLift MajorLift changed the title Add Derive types from authoritative sources guideline TypeScript guidelines: Add Derive types from authoritative sources guideline Jul 16, 2026
Two failure modes the subsection did not yet cover, both from reviewing a
real JS→TS migration:

- The restatement is not always *wider*. Where it is narrower, it is usually
  because a `| undefined` was dropped — which erases the compiler's record of
  why a runtime guard exists, so the guard reads as dead code and gets deleted
  in the same edit, with nothing reported.
- The risk peaks where the compiler *cannot* contradict the guess: a JS caller
  (`checkJs` is off) or a value arriving as `any` means a hand-written
  parameter type is checked against nothing and can drift indefinitely.
  Partially-migrated modules are full of these boundaries.

Adds a second example showing both together: the parameter's real type is
already named in a JSDoc annotation at the call site, the conversion drops its
`| undefined`, and the default parameter that handled the nullable case is
removed alongside it.
@MajorLift
MajorLift force-pushed the jongsun/typescript/derive-from-authoritative-types branch from 12a2c8f to 3c9b1bb Compare July 30, 2026 13:21
… statements

"Almost always wider", "the most common way", and "usually a dropped
`| undefined`" are distributional claims made from a single observed migration.
One of them is contradicted by a case in the same evidence set: a generic result
pinned to one concrete type is a narrowing that involves no nullability at all.

States the two directions a restatement can miss without ranking them, gives
three examples of the narrower direction rather than one presented as typical,
and turns the deleted-guard consequence into a conditional rather than a
tendency.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant