React TypeScript Cheatsheet: opinionated typing advice, generated from docs/

genReadme.mjs rebuilds README.md, so editing it on GitHub is wasted work

The README on the repository page is a generated file. The prose you read is wrapped in marker comments such as START-SECTION:setup and END-SECTION:setup, the root holds genReadme.mjs and copyFile.js, and package.json wires the pipeline to npm run gen-readme, which runs node genReadme.mjs, plus format-readme, which runs prettier over README.md. The source of truth therefore lives in the docs/ directory, and anything you type into README.md in a pull request is discarded on the next run. The consequence for a contributor is a wasted review round unless you edit the section file, and the marker comments are the only clue about which file a given chunk came from. The ToC is generated too, from markdown-toc, so adding a heading without regenerating leaves the page's own navigation out of date.

Five starter kit commands, each tied to a framework rather than to tsc

The setup section does not tell you how to add TypeScript to an existing project. It hands you five commands, one per framework, and every one of them scaffolds rather than converts:

npx create-next-app@latest --ts
npx create-remix@latest
npm init gatsby --ts
npx create-expo-app -t with-typescript
npm create vite@latest my-app -- --template react-ts

Each produces a project whose TypeScript setup is already decided for you, which is the fastest route if you are starting fresh. Read them as a menu rather than a tutorial: the first, third and fifth ask for TypeScript explicitly, while create-remix and create-expo-app carry their own configuration. The one project shape the list does not cover is an existing codebase you want to add types to, and the text sends you to the TypeScript playground, StackBlitz or CodeSandbox at ts.react.new for a scratch reproduction instead.

The prerequisites assume the latest React and TypeScript, and no version is pinned

Two assumptions are stated up front: basic understanding of React, and familiarity with TypeScript basics and everyday types. Then a third, which does more damage than the other two: in the cheatsheet we assume you are using the latest versions of React and TypeScript. There is no version matrix, no compatibility table and no branch per release. The repository has no GitHub releases, so there is nothing to check a diff against, and the last push was on 2026-09-09 to the main branch, which tells you the text moves with upstream React but not which React version any given paragraph was written against. If your application is two majors behind, a snippet can compile on the newest release and still be wrong for you, and the cheatsheet gives you no way to tell which case you are in.

Generic forwardRefs arrives as three options and no decision between them

Most topics in the cheatsheet have one answer. Generic forwardRefs is the exception, and the structure is deliberate. The section splits into Option 1, a wrapper component, Option 2, redeclare forwardRef, and Option 3, a call signature. Each is a different place to put the type parameter, and each has a different cost to the public surface of your component: a wrapper adds a component to the tree, redeclaring puts the work on the consumer, and a call signature keeps the declaration local. The cheatsheet does not rank them. The consequence is on the reader, who has to choose based on constraints the document never asks about, and who finds out later that the wrong choice means rewriting the exported type of a component other people already import. Treat that section as a menu of designs rather than a recipe.

Error boundaries come in a package flavour and a hand-written flavour

The error boundary section has the same two-track shape, with Option 1 using the react-error-boundary package and Option 2 writing your own error boundary component. The two paths are not equivalent in your dependency list, and the cheatsheet presents them as peers. Reading it as a decision: if you take the package option you inherit its API and its release cadence, and if you write the component yourself you own the render behaviour on every React version bump, including the class lifecycle that the custom option depends on. Neither path is described as the default. The same reluctance to pick shows up around concurrent React and React Suspense, where the ToC lists the topic without a stated React version requirement, so you are left matching a paragraph to your own runtime.

Three sections on defaultProps, one of which says you may not need it

defaultProps gets more space than most props topics: You May Not Need defaultProps, then Typing defaultProps, then Consuming Props of a Component with defaultProps with its own Problem Statement and Solution subsections. The heading of the first section is the interesting one, because the cheatsheet signals that the pattern can be unnecessary and then spends the next two sections on typing it anyway. That is a reasonable structure for readers who inherit an existing codebase, and a confusing one for readers starting fresh, who cannot tell whether the following two sections are the recommended path or a compatibility guide. The problem and solution pair for consuming props is the part worth your time if you have met a component whose props vanish at the call site; the other two sections only matter if your code already uses the pattern.

Types or Interfaces? answers with a table, and nothing in the repo enforces it

The types section is the most opinionated part of the cheatsheet, and it is organised around a TL;DR, some further advice and a table comparing types and interfaces, followed by subsections on object as the non-primitive type and on the difference between an empty interface, {} and Object. That is a clear position rather than a survey, which is what the project promises in its opening description. The catch is that nothing in the repository backs the opinion. There is no lint configuration among the top-level files, no eslint rule, no editorconfig and no code style checker, so a codebase that disagrees with the table will not be corrected by anything here and a reviewer citing the cheatsheet has no automated backing. Treat the table as a default to adopt or ignore, then align your own linting with whichever you pick.

LICENSE says MIT and package.json says ISC, which one governs the text

The repository carries a LICENSE file and reports MIT at the repository level, while package.json declares a different identifier, ISC. The manifest explains part of it: its description field reads this package.json is just for maintenance work, and the scripts confirm it, running genReadme.mjs, prettier over markdown files, and a postinstall that changes into the website directory and runs yarn. The manifest exists to build the docs site, not to publish a package, so the ISC field is metadata for tooling rather than a grant to you. Even so, the two files disagree in a way that matters if you plan to copy passages into your own documentation, since nothing in the repository states which file is authoritative for the prose. Read both before you reuse the text wholesale.

Editorial conclusion

Use this cheatsheet when you already know React and are deciding how to type something, and keep the TypeScript handbook open beside it for the language rules it assumes you have. Do not treat the GitHub README as the source you can edit, because genReadme.mjs overwrites it from docs/, and check which licence governs the text before copying snippets wholesale, since LICENSE says MIT and package.json says ISC.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository