A collaboration with Proof · 1 public repo per week

Are you an open source maintainer? We can help your project.

Completely free for open source repositories.

Proof turns your repository into a graph of requirements that humans and agents can both use. It finds as many bugs as it can, and gives you the tools to triage GitHub issues and pull requests from contributors — including community bug reports and security reports.

Apply free for OSS

TypeScript Good First Issues

Leonid Bugaev
|
(Updated August 31, 2026)
|
3 min read
typescript beginners good-first-issue contributing

A first TypeScript pull request is usually one any you can name, or one public type the issue already asked for. It is not a test file. It is not a repo-wide strict flip.

On 2026-08-31 the TypeScript hub had about 8371 labeled issues on repos with 10+ stars. That number moves. Treat it as a size check, then open a live list.

Open the TypeScript hub

Start on helpwanted.dev/language/typescript. That feed is labeled issues on active TypeScript repos, not a gallery of famous names. If TypeScript is not your language, use the homepage.

Pick a type-sized issue

A type-sized first PR looks like:

“Add types” with no file is not sized. “Enable strict across the package” is a migration. One any, one public type. That is the evening.

DefinitelyTyped vs application repos

They are different reviews. Small means different things.

On DefinitelyTyped you change shared .d.ts files. Reviewers care whether the published types match the library and whether downstream compiles. Small there is often one interface field or one overload. Expect a types-focused, slower queue.

In an application repo, small is usually a component prop, a handler argument, or a test helper. Review is that project’s CI and the people who merge app code. A one-file type lands faster than a DT change.

Pick one shape. Do not treat a DT ticket like an app ticket.

Skip claimed threads

If someone already said they are taking it, leave it. A months-old “I’ll take this” with no pull request still counts as claimed. Find a thread nobody reserved. Skip leftover labels on dead repos.

Read CONTRIBUTING.md before you touch tsconfig

TypeScript projects disagree about strict, skipLibCheck, and paths. Touch tsconfig only if the issue asked. A drive-by strict: true is a break, not a first PR. Same for rewriting paths so your editor is happy.

Match their compiler, their test command, and their PR template. Then leave one short comment that you are taking the issue.

Keep the pull request small

Link the issue. Show the type error before and after, or the snippet that compiles now. Do not re-export the world. Do not “clean up” neighboring anys. Stay for review.

FAQ

Is replacing one any a real first PR? Yes, if the issue named the function. A repo-wide any hunt is not.

Should I start on DefinitelyTyped? Only if you can reproduce the library’s types and you want a types-only review. Application repos usually merge a one-file type faster.

Do I need to turn on strict? Not unless the issue said so. strict, skipLibCheck, and paths leak into every file. Leave them unless the ticket named the flag.

What if the issue only says “add types”? Ask which export. If they cannot name a file, pick another ticket.

Where do I look after this page? The live TypeScript hub, then one unclaimed issue you can type in an evening. Language-agnostic picking is in the related posts below. Or start from the homepage.

Back to all articles