The first JavaScript pull request that actually merges is usually a missing example, not a patch to the framework internals. Maintainers label core tickets good first issue because they want help. They merge the PR that makes a documented snippet run again.

Generic hunting lives on how to find good first issues. Multi-language project picking lives on best open source projects for beginners. This URL is the JavaScript filter: what to take as issue one, and what to leave until you have a merge.

Browse the JavaScript hub

JavaScript good first issues →

That page is labeled good-first and help-wanted issues from active GitHub projects whose language is JavaScript. On 2026-08-31 it showed about 4,307 labeled issues at 10+ stars. Snapshot only. The count moves.

If JavaScript is not the language you write, use the homepage instead.

Read the issue body. A title that says “easy” is not a spec. Skip threads that are stale, already claimed, or attached to a repo that has not merged pull requests lately. After you have a candidate, run the issue-level checks in how to pick an issue that will get merged.

There is no list of famous repositories here. Labels on well-known names go cold like everything else. The feed is the hub, ticket by ticket.

First PRs: docs, examples, README snippets, fixtures

In JavaScript, the mergeable first change is often in README, docs/, or examples/.

Typical tickets:

A snippet that still shows the old function name
An examples/ file that throws on main
JSDoc on one export that lies about arguments or return value
A missing usage note the issue already wrote out
A test fixture: JSON, HTML, or a tiny module the suite already imports

Done means the named example runs, the named fixture is loaded by the existing tests, or the named export docs match the code. It does not mean a new docs generator, a reordered tutorial, or a second getting-started path you invented.

Build what the project already uses. If CONTRIBUTING.md names a docs or examples script, that is the loop. Ship the example. Do not restyle the rest of docs/ while you are there.

A docs-only merge is a real first contribution. An unasked rewrite of the guide is noise.

ESLint only if the issue asked

JavaScript repos trip people on lint.

You clone, the editor lights up, and it feels productive to run eslint --fix, add a rule, or clean the file you opened. That pull request is hundreds of quote and semicolon flips. Reviewers treat it as a style fight, not a bugfix. It stalls. It often gets closed.

Rules:

Touch .eslintrc, eslint.config.js, Prettier, or ignore files only if the ticket is the lint rule
Do not add a plugin you like locally
Do not mix a one-line example fix with a format pass
If CI was already warning on lines you did not need, leave those warnings

Lint config is policy. Policy is not a first PR unless it is the issue.

Node vs browser is a different evening

JavaScript is one language and two runtimes. A first issue on a Node library and a first issue in page JS are not the same setup. Pick the runtime you can boot tonight.

Node-shaped. A CLI flag, a parser edge, an error string, an fs or stream case, or a test in node:test, mocha, or tap. You run the project test command. You never open a window. Small means one command and one assertion.

Browser-shaped. A handler, a DOM branch, a fixture HTML page, sometimes a Playwright or Cypress spec if the repo already has that runner. Setup is the dev server they document, not a stack you bring. If the ticket needs a canvas, workers, or a full app shell and you have never run this frontend, it is not issue one.

Do not pick a browser ticket to look more serious when you only have a terminal. Do not pick a Node CLI ticket if the only way you can verify it is a page you cannot stand up.

Match the runtime. Then read CONTRIBUTING.md for that loop.

Framework-core waits for issue two

Leave React, Vue, and other framework-core: the scheduler, the plugin host, the resolver, the shared runtime util everyone imports. Those files have implicit contracts and reviewers who will bounce a plausible patch. A good first issue label on core is a wish for help, not a size.

Issue one is a leaf: the example, the JSDoc, the isolated helper, the test around a public function the ticket named.

Issue two, after you have a merge and have seen how that project reviews, can be closer to core. Not before. You are not behind for skipping the real ticket. You are avoiding a weekend that ends with “please split this” and a closed PR.

Ship one ticket

Filter on the JavaScript hub. Drop stale and claimed threads. Confirm recent merged PRs on that repo.
Read CONTRIBUTING.md for install and test: the package manager, the example script, Node vs browser steps. Get the default branch green before you edit.
Comment on one issue. Do not reserve five.
Keep the diff on the ticket. No ESLint drive-by. Link Fixes #123. Say how you ran the example or the test. Stay for review.

Git after that: first pull request guide. Week-1 map: how to contribute to open source.

FAQ

Is a docs or examples change a real first JavaScript PR?

Yes. A snippet that runs, an examples/ file that stopped throwing, a test fixture the suite already expected, or JSDoc on the export the issue named is a real merge. A volunteer rewrite of Getting Started is not. Do the ticket, not a new tutorial.

Can I run ESLint —fix while I am in the repo?

Only if the issue asked. Lint and Prettier diffs are policy. They bury an example fix and often get the whole PR closed. Leave .eslintrc and eslint.config.js alone unless that file is the ticket.

Should I take a Node issue or a browser issue first?

Whichever runtime you can boot. Node-shaped work is a test command and a CLI or library edge. Browser-shaped work needs the project’s own dev server or fixture page. They are different evenings. Do not mix them to look more complete.

Can my first issue be in the framework core?

No. Skip React, Vue, and other framework-core until issue two. Core files (plugin hosts, resolvers, shared runtime) review like architecture. Issue one is a leaf: docs, an example, a helper, a test on a named public function.

Where do I find live JavaScript good first issues?

On the JavaScript hub. Filter, skip stale and claimed threads, then read CONTRIBUTING.md for the example or test loop. Other languages: the homepage. The generic search playbook is how to find good first issues; this page is the JavaScript filter.

Start here

Open JavaScript good first issues. Pick one unclaimed ticket that is an example, a docs fix, a test fixture, or a leaf helper you can finish in the runtime you have. Comment once, leave ESLint alone, keep the diff on that job, and stay for review.