Open source

Apply to contribute
or maintain hurl

We're looking for developers who understand what they're doing — HTTP internals, edge runtimes, and the discipline it takes to ship a zero-dependency library people depend on in production.

Track 01

Contributor

Submit PRs, build features, fix bugs. You write code that ships.

Track 02

Maintainer

Review PRs, manage issues, own releases. You set the bar.

Basic Info

Full Name *

Email Address * For identity only — we won't email you. Discord is how we reach out.

GitHub Username * We'll verify this is a real account before you can submit.

Discord Username * E.g. firekid or firekid#0001 — this is how we'll contact you if accepted.

Timezone *

Hours per week you can commit *

Portfolio / Personal Website Optional — a link to your site, blog, or anything that represents your work.

General

Q01 How long have you been writing TypeScript professionally or in serious projects? *

Q02 Link 3 GitHub repos you're most proud of — briefly explain what each does and your role in it. *

Q03 Have you ever built or contributed to a library that others depend on in production? Explain what it does and how you thought about breaking changes. *

Zero-Dependency & Bundle Size

Q04 hurl is under 10KB with zero runtime dependencies. Walk us through how you'd add a new feature while keeping that constraint intact — what tradeoffs do you consider? *

Q05 Have you ever had to remove a dependency from a project to reduce bundle size? What did you replace it with and why? *

HTTP & Fetch Internals

Q06 Without using any library, how would you implement retry logic with exponential backoff on a failed fetch request? Write pseudocode or real code. *

Q07 What's the difference between sec-fetch-mode: navigate and sec-fetch-mode: cors? When would each appear? *

Q08 What happens at the network level between calling fetch() and receiving res.data in hurl? *

Edge Runtimes

Q09 Have you deployed code to any of these: Cloudflare Workers, Vercel Edge, Deno, Bun? Which ones and what did you build? *

Q10 What APIs are unavailable in edge runtimes that you'd normally rely on in Node.js? How do you work around them? *

TypeScript

Q11 What's the difference between unknown and any in TypeScript? When would you use each? *

Q12 How would you type a generic response wrapper like hurl's HurlResponse<T>? Write it out. *

Q13 Have you ever written overloads in TypeScript? Show an example or explain when you'd reach for them. *

Problem Solving

Q14 Find a real bug, missing edge case, or genuine improvement in hurl's public API (@firekid/hurl). Describe it in detail — what breaks, why, and how you'd fix it. *

General

Q01 Have you maintained or co-maintained a public npm package? Link it and describe your responsibilities. *

Q02 Link your most impactful code review — what did you catch and why did it matter? *

Q03 How do you decide when a change is a patch, minor, or major semver bump? Give a real example for each. *

API Design & Breaking Changes

Q04 hurl has a public API that developers depend on in production. How do you approach introducing a breaking change? Walk through your full process. *

Q05 Someone opens a PR that solves a real bug but changes the shape of HurlResponse<T>. It's a breaking change but the fix is genuinely needed. What do you do? *

Q06 How do you deprecate something gracefully in a library? What does your ideal deprecation path look like? *

Code Review

Q07 What do you look for first when reviewing a PR for a zero-dependency library like hurl? *

Q08 A contributor submits a feature that works perfectly but adds 4KB to the bundle. How do you handle it? *

Q09 How do you handle a contributor who pushes back hard on your review feedback? *

HTTP & Library Knowledge

Q10 What's request deduplication and when does it break? hurl implements it — can you spot any edge cases? *

Q11 hurl supports interceptors for request, response, and error. How would you test that the interceptor chain executes in the right order? *

Q12 How do you think about caching correctness in an in-memory GET cache like hurl's — what can go wrong? *

Community & Releases

Q13 How do you write a changelog that's useful to developers consuming your package, not just the team? *

Q14 What would your release process look like for hurl — from a merged PR to a published npm version? *

Final

Anything else you'd like us to know? Optional — links, context, or anything that doesn't fit above.

Verify you're human

Verification not showing? Disable your ad blocker or VPN and refresh.

Application submitted

We'll review your application. If selected, you'll hear from us on Discord — make sure you've joined the server.

Applications are reviewed manually. This can take some time.

Apply to contributeor maintain hurl

Application submitted

Apply to contribute
or maintain hurl