GG
Available for remote work
all work
06 / colorsnap

colorsnap

A zero-dependency color utility published to the npm registry. Originally a coursework assignment; kept on the portfolio because shipping a public package, however small, is a useful credibility receipt.

2025·Open source · npm·Author·shipped

This one is small and I want to be honest about that. colorsnap is a zero-dependency color utility — five functions, around 30 lines of code, MIT licensed. It exists because a software-engineering course required publishing a package to a public registry as part of a peer-review exercise. I picked something I could actually justify shipping rather than padding a throwaway tutorial package with fake features.

It's on the portfolio not because it's complicated but because shipping anything to a public registry under your own name is a small kind of professional discipline — picking a name nobody else has taken, writing a README that someone could actually use, getting the package.json right so install works, and accepting that the artifact is now public and your name is on it. Most engineering candidates I've worked alongside have never done this once.

Five functions, picked to be useful enough that someone might actually npm install the package without it being a joke:

randomHex()             // returns "#a3f2c1"
randomRGB()             // returns { r, g, b, string }
randomHSL()             // returns { h, s, l, string }
hexToRGB(hex)           // accepts "#ff5733" or "ff5733"
randomPalette(count=5)  // returns an array of hex strings

Zero runtime dependencies. CommonJS require shape because the assignment didn't specify ESM and a beginner-friendly utility shouldn't force a module-system decision on the consumer. Permissive about input format — hexToRGB accepts both "#ff5733" and "ff5733" because anyone using a color utility has hit that particular foot-gun and there's no reason the library should make them write the unwrap code themselves.

The tests are node test.js — no Jest, no Vitest, no GitHub Actions. For a 30-line library, the cost of a real test setup outweighs the value. The test file imports the module, exercises every function, prints the output, and exits. That's the right amount of testing for the size of the artifact.

The package is intentionally small. Adding more functions — color contrast checks, accessibility-aware palette generation, named-color lookup — would have made it more useful and more interesting, but it would also have made it dishonest about its origin. It's a coursework artifact. Inflating it would have meant either pretending to have spent more time than I did, or actually spending that time on something that wasn't going to teach me anything I didn't already know.

The other tradeoff: I peer-reviewed a classmate's package as part of the same assignment (req-pulse). That review is the part of the exercise that actually mattered — reading someone else's published package, running it locally, writing structured feedback, and learning the etiquette of public open-source review. The artifact on my side of the exchange is colorsnap. The artifact on their side is the review I wrote them.

The package is on npm. The peer review got submitted. The assignment got marked. None of these outcomes are ambitious — that's the point.

Nothing. I'm not going to extend colorsnap into a real color library because there are already excellent color libraries (chroma.js, color, colord) and the world doesn't need another one written by an undergraduate during a course assignment. The package will continue to exist at version 1.0.0 until npm stops hosting it. If I want to ship something more substantial to npm later, it'll be a different package solving a problem I actually have.