A massive, professionally run project that's clear on what it is but hostile to newcomers and locked down for active development.
last scored 2026-06-15
Readiness lenses
The same repo, two ways: how ready it is for an AI coding agent, and for a human newcomer. Switch lenses to see each one's score and checks.
How ready the repo is for an AI coding agent to read, build, and operate it.
26 of 35 checks passed across 6 categories.
Machine Orientation
6 checks passed2 problems found
- lowllms.txt present
An llms.txt is the emerging machine-orientation standard — a curated map for LLMs.
Fix: Add an llms.txt pointing at the key docs and entry points.
- lowArchitecture doc
An ARCHITECTURE doc hands an agent the module map instead of making it infer one.
Fix: Add an ARCHITECTURE.md describing the major components and how they fit.
- README present — An agent reconstructs what the repo is and how to work in it from the README first.
- Agent instructions file — AGENTS.md / CLAUDE.md is the direct, machine-read channel for entry points and conventions.
- Agent instructions stay lean — A bloated instructions file burns context and measurably hurts more than it helps.
- Repository description set — The one-line description is the fastest orientation signal an agent reads.
- Topics set — GitHub topics situate the repo's domain and stack for an agent at a glance.
- Contribution conventions are written down — A contributor guide is where an agent learns the branch, commit, and review conventions it must follow.
Reproducible Setup
5 checks passed1 problem found
- lowEnv template present
A .env.example tells an agent which configuration keys it must supply to run.
Fix: Ship a .env.example listing every required key with placeholder values.
- Lockfile committed — Without a lockfile two clones can resolve different dependency trees — the build isn't reproducible.
- Runtime / toolchain pinned — An unpinned runtime makes an agent guess the version a clean environment needs.
- Version pins are exact — A floating pin (a bare major, or a range) still drifts between installs.
- Container or dev-container — A Dockerfile / compose / devcontainer removes 'works on my machine' from setup.
- Dev container — A .devcontainer gives an agent a one-command, fully-declared environment.
Code Navigability
1 check passed1 problem found
- lowTypeScript strict mode on
Strict typing gives an agent typed signatures to anchor an edit on, not guesses.
Fix: Turn on `strict` in tsconfig.json.
- Conventional source layout — A recognised src/ · lib/ · app/ layout lets an agent localise code without spelunking.
Verification Surface
6 checks passed1 problem found
- lowTask runner present
A Makefile / Taskfile / justfile gives an agent a single index of the project's commands.
Fix: Add a Makefile / Taskfile / justfile collecting the common commands.
- Tests present — Runnable tests are the ground truth an agent checks its own edits against.
- Test command defined — A `test` script is the documented, discoverable way to run the suite.
- Lint command defined — A linter an agent can run catches a class of mistakes before they ship.
- CI configured — Readable CI is the feedback loop an agent reads to know what 'green' means here.
- Typecheck command — A typecheck script lets an agent catch type errors before they ship.
- Build command — A documented build command is the discoverable way for an agent to produce artifacts.
Agent Safety
6 checks passed2 problems found
- medium.gitignore covers env files
An ignore rule for .env is what keeps the next careless commit from leaking secrets.
Fix: Add `.env` (and `.env.*`) to .gitignore.
- lowCODEOWNERS present
CODEOWNERS marks the 'don't touch without review' zones an agent should respect.
Fix: Add a CODEOWNERS file marking the sensitive paths.
- No committed .env — A tracked real .env hands secrets to anything — including an agent — that reads the repo.
- No exposed secrets — Secret-shaped literals in tracked files are a live credential leak.
- Automated dependency updates — Dependabot / Renovate keeps dependencies patched without a human in the loop.
- .gitignore present — A .gitignore is the first guard against an agent committing secrets or build junk.
- Security policy — A SECURITY.md is where an autonomous security agent reads this repo's rules before acting on it.
- License makes the code reusable — Without a license an agent cannot safely copy, redistribute, or vendor any of this code.
Context Economy
2 checks passed2 problems found
- mediumDependencies not vendored in
A committed node_modules / vendor tree drowns the real signal an agent needs.
Fix: Remove the vendored dependency directory and gitignore it.
- lowNo oversized source file
A single file in the hundreds of KB blows past an agent's effective context window.
Fix: Split the largest files along their natural seams.
- Build output not committed — Generated dist/ · build/ output is noise an agent has to read past.
- Generated / vendored files marked — A .gitattributes linguist marker tells tools (and agents) what to skip.
How ready the repo is for a human newcomer to understand, set up, and contribute.
72 / 10020 of 25 checks passed across 6 categories.
First Impression
88Crystal-clear purpose, mature brand, and extensive supporting material — you know exactly what TypeScript is.
The README immediately states the project's purpose ('language for application-scale JavaScript'), links to a playground, blog, and community resources, and provides installation and contribution paths. Badges show active CI and npm downloads. The only friction is the prominent warning that code changes are severely restricted, which may confuse newcomers about contribution eligibility.
Getting Running
65Install is trivial, but building and developing locally require hidden knowledge and cross-referencing multiple files.
Installation for users is one-liner (`npm install -D typescript`), and the package.json specifies pinned Node (22.22.0) and npm (8.19.4) versions via Volta. However, dev setup is obscured: build commands are in a Herebyfile (not package.json), the build entry point isn't obvious, and there's no explicit 'clone → develop → test' walkthrough. The snapshots don't show a Herebyfile content, so a newcomer must infer from CI files or hunt through docs.
Finding Your Way
76Clear module structure (src/compiler, src/harness, src/lib) and consistent naming, but no architecture guide or diagram to anchor a newcomer.
The file tree reveals well-organized subdirectories: compiler logic, test harness, library definitions, transformers for each ES target, and scripts for builds. Naming is descriptive (binder.ts, checker.ts, emitter.ts). However, there's no architecture overview, data flow diagram, or high-level guide explaining how parser → binder → checker → emitter connects. A newcomer must reverse-engineer this from source.
Path to Contribute
44Contribution is officially discouraged; the project is on life-support for the JS version, and most PRs will be rejected outright.
The README and CONTRIBUTING.md explicitly state that code changes are limited to critical 6.0 fixes, security issues, and serious regressions from 5.9. Most feature requests and bug fixes go to typescript-go. CONTRIBUTING.md also warns against AI-driven bulk submissions and auto-generated comments. While a CONTRIBUTING.md exists and lists ways to engage (issue triage, discussion, etc.), the barrier to landing code is extremely high and discourages typical first-time contributors.
Signs of Life
88Active at scale — 109k stars, frequent commits, mature release cycle, and Microsoft-backed maintenance.
Last push is recent (2026-06-12), 5040 open issues shows triage at scale, and the file tree includes multiple CI/CD workflows (ci.yml, nightly, release branches, codeql). The repository has release branches, insiders builds, and orchestrated releases. Package version 6.0.0 and pinned tool versions (esbuild, dprint, mocha) show professional release discipline.
Open Door
81Legal and social safety are clear: Apache 2.0 license, Code of Conduct, and explicit support channels, but AI contribution rules are unusually strict.
LICENSE.txt is present (Apache 2.0), CODE_OF_CONDUCT.md exists and links to Microsoft's OSS Code of Conduct, and SUPPORT.md provides help channels (issues, Discord, Stack Overflow, Twitter). However, CONTRIBUTING.md includes a firm ban on bulk AI-driven contributions with warnings about account blocking — stricter than typical open-source. This signals a healthy gate against spam, but newcomers using AI tools must disclose and be aware of the project's stance.
First Impression
3 checks passed0 problems found
- README present — The README is the first screen — with none, a newcomer has nothing to land on.
- Repository description set — The one-line description sets expectations before a newcomer even opens the README.
- Topics set — Topics situate the project's domain at a glance and help a newcomer find it.
Getting Running
5 checks passed1 problem found
- lowEnv template present
A .env.example shows a newcomer exactly which settings they must fill in to run it.
Fix: Ship a .env.example listing every required key with placeholder values.
- Lockfile committed — Without a lockfile a newcomer's install resolves differently and hits errors the docs don't mention.
- Prerequisite versions pinned — Unpinned prerequisites are the classic 'works on my machine' first-run failure.
- One-command environment — A Dockerfile / compose / devcontainer turns a fiddly setup into one command.
- One-click dev container — A .devcontainer lets a newcomer start in a cloud IDE with zero local setup.
- Versions pinned exactly — A floating version still drifts — a newcomer can hit a break the maintainer never saw.
Finding Your Way
1 check passed2 problems found
- mediumArchitecture / overview doc
An overview hands a newcomer the map instead of making them reconstruct it.
Fix: Add an ARCHITECTURE.md (or a 'Project layout' README section) naming the key directories.
- lowNo oversized source file
A single thousand-line file is a wall a newcomer bounces off.
Fix: Split the largest files along their natural seams.
- Conventional source layout — A familiar src/ · lib/ · app/ layout lets a newcomer guess where things live.
Path to Contribute
4 checks passed2 problems found
- lowPull-request template
A PR template tells a first-time contributor what a good change includes.
Fix: Add a PULL_REQUEST_TEMPLATE.md.
- lowTask runner
A Makefile / Taskfile gives a contributor a single index of the project's commands.
Fix: Add a Makefile / Taskfile collecting the common dev commands.
- CONTRIBUTING guide — A CONTRIBUTING guide is the difference between a guessed and a guided first PR.
- Issue templates — Issue templates show a newcomer how to file something useful — and that contributions are welcome.
- Test command defined — A documented test command lets a contributor check their change before opening a PR.
- Lint command — A linter lets a first-time contributor catch style issues before review.
Signs of Life
3 checks passed0 problems found
- Tests present — A test suite signals a project that's cared for, not abandoned.
- CI configured — Green CI on every change tells a newcomer the project is actively kept working.
- Automated dependency updates — Dependabot / Renovate activity is a visible heartbeat of ongoing maintenance.
Open Door
4 checks passed0 problems found
- License present — With no license the project isn't legally reusable — the door is shut however friendly the README.
- License is a standard one — A non-standard or custom license is a legal question mark a newcomer won't resolve.
- Code of conduct — A code of conduct states the social ground rules that make it safe to step in.
- Security policy — A SECURITY.md tells a newcomer how to report a problem responsibly.
Where the grip slips
- highPath To Contribute+20 pts if fixed
Development locked down; most contributions will be rejected
The project explicitly states that code changes are limited to critical 6.0 fixes, and feature work is directed to typescript-go. CONTRIBUTING.md opens with a warning that 'all code changes should be submitted to typescript-go' and PRs only merge if they fix 'critical' issues. A newcomer who wants to contribute will hit rejection immediately, making the contribution path feel closed despite a CONTRIBUTING.md existing.
Fix: Add a prominent section at the top of CONTRIBUTING.md explaining the current state (JavaScript version in maintenance mode, Go version is active) and linking newcomers directly to typescript-go if they want to make feature contributions. Clarify which issues are in-scope for this repo and which belong in typescript-go. Consider an issue template that auto-routes off-topic contributions.
- highGetting Running+18 pts if fixed
No documented dev setup or build guide
The build is managed by Herebyfile (a Gulp-like task runner), but the snapshot doesn't include its contents. Package.json has scripts (`npm run build`, `npm run build:compiler`), but there's no step-by-step guide explaining what these do, how long they take, what dependencies they need (beyond Node/npm), or what to do if they fail. A newcomer must infer workflow from CI files or trial-and-error.
Fix: Create a DEVELOPMENT.md or expand README with: (1) Prerequisites checklist (Node 22.22.0, npm 8.19.4, optional: VSCode extensions listed in .vscode/extensions.json); (2) Clone and setup (git clone, npm install); (3) Build steps with expected output (npm run build:compiler, npm run build:tests); (4) Run tests (npm test); (5) Common issues (e.g., Volta setup, TypeScript version overrides). Link from README.
- mediumFinding Your Way+15 pts if fixed
No architecture overview or module guide
The source tree has logical structure (compiler/, harness/, lib/, transformers/), but there's no high-level explanation of how components interact: what is the parser-to-emitter pipeline? What does the harness do? How do transformers fit in? A newcomer trying to understand where to start for a bug fix or feature must read source code without a map.
Fix: Add docs/ARCHITECTURE.md explaining: (1) High-level pipeline (parse → bind → check → transform → emit); (2) Key modules (compiler, checker, emitter, transformers) and their roles; (3) Data flow diagram or pseudocode showing how a .ts file becomes .js; (4) Harness and test structure; (5) Links to key files. Keep it brief (< 500 words) and add cross-references.
- mediumOpen Door+10 pts if fixed
Strict AI contribution rules without onboarding
CONTRIBUTING.md warns against AI-authored PRs without disclosure and threatens account blocking for bulk agent submissions. While this protects the project from spam, it's intimidating and unusual, and newcomers using Copilot or Claude may not know they must disclose. The tone is enforcement-heavy rather than guidance-light.
Fix: Restructure the AI section with: (1) A welcoming intro: 'Using AI tools is fine, here's how'; (2) Clear rules: disclose AI involvement in PR description, one issue per PR, human review before submission; (3) Examples of acceptable vs. unacceptable workflows; (4) Link to a template PR description. Move threat of blocking to end and frame as last resort for repeated violations, not default expectation.
- lowGetting Running+5 pts if fixed
Volta pinning is good but not mentioned in dev setup
package.json includes Volta configuration (Node 22.22.0, npm 8.19.4) which ensures version consistency, but there's no README or DEVELOPMENT.md step explaining this. A newcomer on an older Node might hit subtle issues without knowing why, or might install Volta unnecessarily if setup is unclear.
Fix: In dev setup docs, add: 'This project uses Volta to pin Node and npm versions. If you have Volta installed (https://docs.volta.sh/guide/getting-started), run `volta install` to get the correct versions. Otherwise, manually install Node 22.22.0 and npm 8.19.4.'
Show your score
[](https://latch.fyi/microsoft/typescript)Share this analysis
https://latch.fyi/microsoft/typescriptFixed some issues? Re-analyze to measure your progress →
Copy the whole report
Grab the entire verdict in one go — a Markdown block for a README or an issue, plain text, or a prompt you can paste straight into an LLM.