
Research Ts Decisions
- 8 installs
- 8.6k repo stars
- Updated April 1, 2026
- mattpocock/ts-reset
Research and document TypeScript architectural decisions, surfacing best practices and tradeoffs from the ts-reset project for informed TS configuration choices.
About
A research skill from the mattpocock/ts-reset project that investigates and documents TypeScript architectural decisions, surfacing best practices and tradeoffs for tsconfig and type patterns. Reach for it when your team needs to make deliberate, well-documented TypeScript choices and wants guidance grounded in real-world TS expertise.
- Researches TypeScript configuration decisions
- Documents TS best practices from ts-reset
- Helps teams make informed tsconfig choices
- Surfaces tradeoffs in TypeScript patterns
Research Ts Decisions by the numbers
- 8 all-time installs (skills.sh)
- +1 installs in the week ending Aug 4, 2026 (Skillselion tracking)
- Ranked #1,171 of 1,879 Documentation skills by installs in the Skillselion catalog
- Data as of Aug 4, 2026 (Skillselion catalog sync)
npx skills add https://github.com/mattpocock/ts-reset --skill research-ts-decisionsAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 8 |
|---|---|
| repo stars | ★ 8.6k |
| Last updated | April 1, 2026 |
| Repository | mattpocock/ts-reset ↗ |
What it does
Research and document TypeScript architectural decisions, surfacing best practices and tradeoffs from the ts-reset project for informed TS configuration choices.
Who is it for?
TypeScript developers making informed configuration and type pattern choices
Skip if: Non-TypeScript projects
When should I use this skill?
You need to research and document TypeScript decisions for your project
What you get
- TypeScript decision document
- tsconfig recommendations
Files
Research TypeScript Team Decisions
When evaluating whether ts-reset should override a TypeScript built-in type, research what the TypeScript team has said about it. Understanding their reasoning lets us make informed decisions — either agreeing with their trade-off or deliberately choosing a different one.
Who to look for
Ryan Cavanaugh (@RyanCavanaugh) is the TypeScript project lead and usually the one making final verdicts on typing decisions. His comments carry the most weight. Also look for comments from:
- Daniel Rosenwasser (
@DanielRosenwasser) — TS program manager - Anders Hejlsberg (
@AHejlsberg) — original designer - Nathan Shively-Sanders (
@sandersn)
How to search
Step 1: Search GitHub issues directly
Use gh to search the microsoft/TypeScript repo. Try multiple queries — the issue might be about the specific method, the return type, or a broader pattern:
# Search issues by title/body
gh search issues --repo microsoft/TypeScript "Object.create return type" --limit 20
# Search with broader terms if the first query is too narrow
gh search issues --repo microsoft/TypeScript "Object.create" --limit 20Step 2: Find team member comments
Once you have candidate issues, fetch comments and filter for TypeScript team members:
# Get Ryan's comments on a specific issue
gh api repos/microsoft/TypeScript/issues/{number}/comments \
--jq '.[] | select(.user.login == "RyanCavanaugh") | {html_url, body}'
# Check for team comments more broadly
gh api repos/microsoft/TypeScript/issues/{number}/comments \
--jq '.[] | select(.user.login == "RyanCavanaugh" or .user.login == "DanielRosenwasser" or .user.login == "sandersn" or .user.login == "ahejlsberg") | {user: .user.login, html_url, body}'Step 3: Check for reverted PRs
Many typing decisions were tried, broke things, and got reverted. This history is critical:
# Search for PRs related to the topic
gh search prs --repo microsoft/TypeScript "Object.create" --limit 20
# Check if a PR was later reverted
gh api repos/microsoft/TypeScript/pulls/{number} --jq '{title, state, merged_at, body}'Step 4: Search for related issues
TypeScript team members often state general principles on tangentially related issues. If the specific method doesn't have much discussion, search for related patterns:
# Example: if researching Object.create, also check Object.getPrototypeOf,
# or broader topics like "prototype typing" or "returns any"
gh search issues --repo microsoft/TypeScript "Object.getPrototypeOf any" --limit 10Step 5: Web search as fallback
If GitHub search doesn't surface enough, use web search:
site:github.com/microsoft/TypeScript "Object.create" RyanCavanaughWhat to report
Structure your findings as:
1. Timeline — chronological list of relevant issues and PRs, with links 2. Key quotes — direct quotes from team members, with permalink URLs to the specific comments (not just the issue) 3. The reasoning — summarize why the current typing exists 4. Was it tried before? — note any attempts to change it that were reverted or rejected, and why 5. Relevance to ts-reset — does this fall in ts-reset's sweet spot, or is the current typing a deliberate trade-off?
Always include direct permalink URLs to specific comments, not just issue URLs. Use the html_url field from the GitHub API.
Common patterns in TS team reasoning
These recurring arguments come up frequently. Knowing them helps you search more effectively and contextualize what you find:
- "`any` can never be wrong, just less right" — Ryan's principle that
anyis a safe default that never produces false errors - Breaking changes — the TS team is very cautious about changing return types that would break existing code
- "Soundness is not a goal" — TypeScript explicitly prioritizes practical usability over type-theoretic correctness
- Prototype vs own properties — methods dealing with prototypes are hard to type because TS's type system doesn't distinguish prototype properties from own properties
- `PropertyDescriptorMap` is untyped — any API that takes property descriptors can't carry type information through them