Looking to make my first contribution to Next.js

[scs0209]

Summary

Hi everyone!

I'm a frontend developer and I've been using Next.js in my projects.

I'd like to start contributing to Next.js and make my first open-source contribution. I've been looking through the open issues, but I'm not sure which ones would be a good fit for a first contribution.

Are there any smaller bugs or improvements that you'd recommend I work on?

I'm happy to investigate the issue, add tests where appropriate, and submit a PR.

Thanks for your time, and thanks for maintaining Next.js!

Additional information

No response

Example

No response

[justin24er]

Hey! Good first move is checking issues tagged "good first issue" in the Next.js repo directly good first issues, those are specifically curated for newcomers and usually well-scoped.

A couple extra tips: docs fixes and small reproducible bug fixes (especially around error messages, warnings, or CLI output) tend to be great starter PRs since they're low-risk and easy for maintainers to review fast. Also worth skimming the CONTRIBUTING.md first, Next.js has a solid setup guide and testing conventions that'll save you time once you pick an issue. Good luck with your first PR!

[scs0209]

Thanks for the tips — really helpful!

I checked the good first issues, but many of them look quite old / inactive. I’ll try looking around the docs side for something smaller I can help with.

Appreciate you taking the time to reply!

[justin24er]

much love!

[dvd233]

Welcome! The good first issue label linked above is the right starting pool. A few things that made my own first contributions go smoothly:

1. Prefer issues with a clear reproduction. A bug report with a runnable repro repo is worth ten "it would be nice if" issues — you can verify the bug locally before writing any code, and your fix can be verified by a failing-then-passing test.

2. Read the contributing docs before writing code. https://github.com/vercel/next.js/blob/canary/contributing.md covers the local setup (pnpm, building from source) and — importantly — that bug-fix PRs are expected to include a regression test (usually an e2e test under test/). A fix without a test often stalls in review even when the fix itself is correct.

3. Expect the test suite to be the hard part. Running a single e2e test file (pnpm testonly test/e2e/<dir>/) is much faster than the whole suite. Get one test running locally first; that's the real "hello world" of contributing here.

4. Pick issues that fix a concrete problem someone actually has. Pure wording/style tweaks (e.g. normalizing a phrasing in docs) tend to get closed — maintainers judge docs and product copy by intent, not by spell-checker output. Correctness bugs, broken examples, and misleading error messages are much safer territory.

5. It's fine to claim an issue by just starting. Drop a short comment like "I'm looking into this" so others don't duplicate the work, and don't hesitate to open a draft PR early to get feedback on the approach.

Good luck — looking forward to your first PR!

[scs0209]

Thanks so much for the detailed tips — especially the points about clear reproductions and including a regression test. Really helpful as I get started!

[gilangabdian]

If you are new to this but already have knowledge of Next.js, I think you can jump straight into fixing technical code-related issues. My advice is to look for the latest issues; if no one has fixed one yet, leave a comment—like "Can I fix this issue?"—so others don't work on the same thing. If the issue creator agrees, you can go ahead and work on it. However, if you are sure that no one will work on the issue then you don't need to give a message as it seems like it's okay🤔.

However, when I first started, I mostly looked for typos or documentation that I found awkward. I would either create an issue for them or, more often, start a discussion in the Next.js "Discussions" tab to talk it over with more experienced contributors.

Besides that, I also tried to find //TODO comments in the next.js codebase to complete. In my opinion, this method is very suitable for beginner contributors because we don't need to bother changing the internal code of next.js. However, we have to make sure that the code for the //TODO comment must be relevant and not cause errors for next.js itself.

[scs0209]

Thank you for the advice! Looking for recent issues and claiming them with a short comment is a great approach — I'll keep that in mind. Appreciate you sharing your experience!

[guillaumebrunerie]

This is pretty bad advice, actually, please don’t leave comments like "Can I fix this issue?", this is just spam. If you think you can fix an issue, just try to do it, and send a pull request if you manage to actually fix it.

[gilangabdian]

Sorry for the bad advice, because here I just want to share my experience and don't mean to make things worse.