DEV Community: kwy404

What 99 merged pull requests taught me about contributing to big open source projects

kwy404 — Sat, 03 Oct 2026 01:27:04 +0000

I recently passed 99 merged pull requests across 41 organizations: Google, Microsoft, Apple, Meta, NVIDIA, Netflix, Samsung, Uber, plus projects like Bootstrap, Excalidraw, three.js, MUI, Tailwind CSS and Puppeteer.

None of them is a big feature. Almost all are small bug fixes, often under 15 lines including the test. This post is about how that works in practice: how I pick bugs, how I write a PR a maintainer can merge in two minutes, and the lessons I got from the times a maintainer said "not like this".

Pick bugs you can prove
The best contributions I made all had one thing in common: before touching the code, I could write a test that failed.

I look for bugs in the boring places:

Parsers and formatters. Edge cases like empty input, a trailing separator, a negative number, a character that needs escaping.
Boundaries. < versus <=, off by one, a range that is empty.
Unit conversions. Nanoseconds versus microseconds, rounding, sign handling.
Places where two code paths should agree but don't. One branch escapes a value and the other one forgets.
These bugs are small, but they are real, and someone somewhere is hitting them.

Five bugs I enjoyed fixing

An HTML entity inside a regular expression (Red Hat, vscode-yaml). The auto indentation rule for YAML was supposed to indent after a key with an anchor, like base: &base. It never did. The pattern in language-configuration.json contained & instead of &, so it was looking for the literal text &. A one character fix, plus a test that reads the real config file. Then a maintainer found that &ref-erance still failed, because the pattern only allowed word characters after &. YAML anchors can contain almost anything, so the second commit fixed that too.
One character in a drag and drop check (Meta, Lexical). Dropping dragged text exactly on the edge of its own selection deleted the text. The check used < where it needed <=. The maintainer extended the fix before merging, and the boundary change and the test stayed.
"60.0s" in a build log (ByteDance, Rsbuild). A build that took 59.96 seconds was logged as 60.0s, and one that took 119.96 seconds as 1m 60.0s. The function checked < 60 and split minutes and seconds on the raw value, and only rounded at the very end. Rounding first fixed both. Tiny, visible, and easy to test.
Decimal breakpoints in Tailwind CSS. Breakpoints in the same unit were compared with parseInt, which drops the fractional part, so 40.25rem and 40.5rem looked equal. min-[40.5rem] could be emitted before min-[40.25rem], and the smaller breakpoint won in the cascade. Switching to parseFloat fixed the order, with a test for decimal values.
A three.js geometry edge case. Line3.distanceSqToLine3() also writes the two closest points into optional targets. When both segments were degenerate (start equal to end), an early return computed the distance with c1.sub( c2 ), so c1 ended up holding a difference vector instead of a point. A previous fix had covered the general case but missed this branch. The test now checks both points for two degenerate segments.

How I write the pull request
Maintainers of big projects review a lot of PRs. Mine follow the same shape every time:

Root cause first. One or two sentences that explain why the bug happens, not just what changed. "The pattern contains &, so it never matches &" is better than "Fix indentation".
The fix. What I changed and why it is the smallest correct change.
The test. A test that fails before the change and passes after it. I say that explicitly in the description, and I run it both ways before opening the PR.
I also follow each repository's own conventions: commit message style, PR template, changelog or changeset files, CLA or DCO. Reading CONTRIBUTING.md before writing any code saves a round of review.

Keep the diff small. A five line fix with a test gets merged in days. A refactor that "cleans things up while I'm here" sits for months.

What maintainers taught me
The most useful part of this was not the merges. It was the reviews.

"Fix the cause, not the symptom." In one project I made a duration formatter handle negative values. The maintainer replied that negative durations should be impossible at that point and should never reach the formatter. They were right: the real issue was a function that passed a signed difference between two durations. I moved the fix there and left the formatter alone.

"A narrow fix is not always worth the review." I fixed a host parsing bug for IPv6 addresses in a networking library. The maintainer explained that a one off IPv6 fix does not help much if the rest of the stack cannot run over IPv6 yet, and every PR costs review and CI time. That was a fair point, so I closed the PR. Sometimes the right contribution is an issue with a plan, not code.

Maintainers often improve your fix. In Lexical the maintainer extended my change before merging. In Adobe's Spectrum Web Components a maintainer carried two of my fixes into their own PRs with co-author credit. In DataComPy the maintainer wrote an extra test for a two column key case. None of that is a rejection. It is how you learn how a codebase is meant to work.

Small process details matter. One PR was approved and then blocked because the repository requires signed commits. Setting up commit signing took five minutes and unblocked it.

A checklist you can steal
Read CONTRIBUTING.md and the PR template before writing code.
Search open and closed PRs and issues for the bug first. Someone may already be on it.
Reproduce it with a failing test.
Make the smallest change that fixes the root cause.
Run the test without your change, then with it.
Run the project's linters and formatters on the files you touched.
Explain the root cause in the first lines of the description.
Answer review comments quickly, and say thanks.
Why bother
Open source is one of the few places where you can learn directly from engineers who maintain software used by millions of people, and where your work is public and verifiable. Every one of these PRs is a small, reviewed piece of evidence of how you write code.

If you want to see the full list, it is on my GitHub profile: github.com/kwy404.

If you have never contributed to a big project before: pick one you use every day, find one small bug you can prove with a test, and send it. The first merge is the hardest one.

I Built Voodoo.js to Bring TSX and Reactivity Directly Into Plain HTML

kwy404 — Fri, 04 Sep 2026 22:47:57 +0000

What if you could write reactive interfaces, map arrays, filter data, use components, and even write JSX style syntax directly inside a plain HTML file?

That is the idea behind Voodoo.js.

Voodoo.js is an HTML first JavaScript framework designed for developers who want modern frontend capabilities without introducing a complex toolchain.

You can start with a single script tag and keep working directly inside your HTML.

No bundler.

No compiler.

No configuration.

No project scaffolding.

Just HTML, JavaScript, and reactivity.

In stock

{i + 1}. {p.name} {p.stock} left

The interesting part is that this is still a normal HTML file.

You can use familiar JavaScript methods such as filter, sort, and map while generating reactive markup directly inside the page.

For developers coming from React, Vue, Alpine, or even vanilla JavaScript, the syntax should feel immediately familiar.

But the philosophy is different.

HTML stays at the center of the application.

Voodoo.js adds the reactive layer around the markup you already have instead of forcing your HTML into a completely different application structure.

One script tag

Getting started can be as simple as adding Voodoo.js to an HTML page.

From there you can use reactive data, events, expressions, components, HTTP utilities, forms, and JSX style templates.

There is no required build pipeline.

That also makes Voodoo.js interesting for prototypes, small applications, internal tools, static websites, experiments, and developers who simply enjoy working close to the browser.

The Playground

I also built an interactive playground where you can experiment with the framework directly in the browser.

You can edit the HTML, run the example, and immediately see the result in the live preview.

Try the JSX map example here:

https://kwy404.github.io/Voodoo.js/playground.html#jsx-map

Project website:

https://kwy404.github.io/Voodoo.js/

GitHub:

https://github.com/kwy404/Voodoo.js

Voodoo.js is open source and still evolving.

I would really like feedback from other JavaScript developers.

What do you think about this approach?

Would you use JSX or TSX style syntax directly inside an HTML file if it meant keeping the project simple and avoiding a build step?

If you find the project interesting, consider checking the repository, opening an issue, contributing, or giving it a star on GitHub.

JavaScript #TypeScript #TSX #JSX #WebDevelopment #Frontend #FrontendDevelopment #OpenSource #HTML #WebDev #Programming #Coding #DeveloperTools #JavaScriptFramework #VoodooJS

A reactive JS framework for server-rendered apps — no Virtual DOM, no eval(), no build step required. Looking for critical feedback.

kwy404 — Mon, 31 Aug 2026 20:01:48 +0000

I've been building a JavaScript framework called Voodoo.js, and I'd rather get torn apart in the comments than hear that it looks cool.

It started with one question:

How much JavaScript do we actually need to write for everyday interactive interfaces?

For a lot of apps I don't want to build a component tree, configure a bundler, install five libraries, wrap the API, manage state somewhere else, and then wire it all back into HTML.

Sometimes I just want to keep writing HTML.

GitHub: https://github.com/kwy404/Voodoo.js

The 30-second version

A reactive counter:

<div v-data="{ count: 0 }">
  <button @click="count--">-</button>

  <strong>{ count }</strong>

  <button @click="count++">+</button>
</div>

No querySelector. No addEventListener. No innerHTML. No Virtual DOM.

Voodoo observes the real DOM and connects HTML directives to a fine-grained reactive system built on Proxy.

"Why another JS framework?"

Fair question. It's the first one I'd ask too.

Voodoo isn't trying to replace React, Vue or Svelte. The target is different: projects where the server already renders the HTML.

Laravel, Django, Rails, PHP, ASP.NET, Node, Go templates — plus small frontends where a full SPA is overkill.

Philosophically it lives somewhere near Alpine.js, HTMX and petite-vue. The difference I was chasing: HTTP, forms, validation, state, components, routing, UI helpers and reactivity should feel like one system, not five glued together.

Declarative HTTP

This is the part I enjoy using most.

Instead of wiring a button by hand:

button.addEventListener('click', async () => {
  if (!confirm('Delete user?')) return

  await fetch('/api/users/42', { method: 'DELETE' })

  showToast('User deleted')
})

You declare the intent:

<button
  v-delete="/api/users/42"
  v-confirm="Delete this user?"
  v-toast-success="User deleted">
  Delete
</button>

The goal isn't to make JavaScript disappear. It's to stop writing JavaScript that only restates what the HTML already says.

Forms

Same idea:

<form
  v-submit="/api/users"
  v-validate
  v-toast-success="User saved">

  <input name="email" type="email" required>

  <button type="submit">Save</button>
</form>

For most CRUD screens, that's the whole thing. When you need more, plain JavaScript is still right there. Voodoo is meant to be progressive, not restrictive.

No `eval()`, no `new Function()`

Take this:

<button @click="count++">

The lazy implementation is new Function(expression) or eval(expression). Voodoo does neither.

There's a full expression engine inside:

Lexer → Pratt Parser → AST → Interpreter

Expressions are parsed and interpreted by Voodoo itself. That gives the framework control over which syntax is supported and what the expression environment can touch — and honestly it's the most interesting engineering in the project.

Fine-grained reactivity

The reactive layer uses Proxy, tracking dependencies per object and per property:

reactive object
    ↓ property accessed
dependency tracked
    ↓ property changed
only dependent effects run

No Virtual DOM diff between updates. The real DOM is patched directly.

The reactivity package exposes a familiar surface:

reactive()   ref()        computed()
watch()      watchEffect() effectScope()
toRaw()      markRaw()

If you've used a modern reactive framework, none of this should surprise you.

Works with or without a build step

Drop it in:

<script src="voodoo.js"></script>

<div v-data="{ open: false }">
  <button @click="open = !open">Toggle</button>

  <div v-show="open">Hello DEV Community 👋</div>
</div>

Or import it like anything else:

import { reactive } from 'voodoojs/reactivity'

Both audiences matter to me: the "paste a script tag" crowd and the "give me proper ESM" crowd.

Where it fits

Server-rendered HTML  +  Voodoo.js  →  Reactive interface

A Laravel view, for example:

@foreach($users as $user)
  <button
    v-delete="/users/{{ $user->id }}"
    v-confirm="Delete user?">
    Delete
  </button>
@endforeach

The backend keeps rendering the app. Voodoo adds the interactive layer. No separate frontend application.

The honest part

What began as an experiment grew into a large framework: reactivity, directives, components, stores, HTTP, forms, validation, persistence, routing, i18n, UI utilities, animation, drag and drop, charts, streaming, devtools, and a CLI.

That growth is now the problem. The project doesn't need another hundred features — it needs stability.

Current focus:

🔒 Security hardening
🧩 Parser edge cases
✅ Test coverage
📐 API stability
📦 Bundle modularity
⚡ Performance benchmarks
📚 Documentation
🚀 Package and release quality

I'd rather ship a small set of features people can trust in production than a huge one nobody can.

What I'm asking for

If you work with Alpine.js, HTMX, Vue, petite-vue, Stimulus, Livewire, server-rendered apps, or plain JS — I want your read on this:

What would stop you from using something like Voodoo.js?
Which parts of the API feel intuitive?
Which parts feel unnecessary?
What would you need to see before calling it production-ready?

And if you like working on JS internals, there's real work available: parsers, reactivity, testing, browser compatibility, TypeScript, performance, security, docs, components.