research-ts-decisions
Investigate why TypeScript uses a particular built-in type by tracing issues, proposed changes, and team comments. Produces a linked timeline and explanation of past trade-offs to help assess type overrides in ts-reset or proposed typing changes.
中文简介正在准备中。当前显示英语简介。
原文查看原文说明
Research why the TypeScript team made a specific typing decision. Use when evaluating whether ts-reset should override a built-in type, or when triaging issues that propose type changes. Searches the microsoft/TypeScript repo for relevant issues, PRs, and team comments.
适用场景
- Investigate the reasoning behind a built-in type
- Assess a proposed type override in ts-reset
- Find rejected or reverted typing changes
- Collect team comments with direct links
包含的文件(1)
- SKILL.md4.5 KB
SKILL.md(原文)
安装前可以查看交给 AI 代理的指令内容。
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 20
Step 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 10
Step 5: Web search as fallback
If GitHub search doesn't surface enough, use web search:
site:github.com/microsoft/TypeScript "Object.create" RyanCavanaugh
What to report
Structure your findings as:
- Timeline — chronological list of relevant issues and PRs, with links
- Key quotes — direct quotes from team members, with permalink URLs to the specific comments (not just the issue)
- The reasoning — summarize why the current typing exists
- Was it tried before? — note any attempts to change it that were reverted or rejected, and why
- 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:
- "
anycan never be wrong, just less right" — Ryan's principle thatanyis 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
PropertyDescriptorMapis untyped — any API that takes property descriptors can't carry type information through them
评价
还没有评价。欢迎分享你的使用感受。
评论
无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。
还没有评论。来写第一条吧。