One developer, evenings and weekends.
FieldCraft is built and maintained by one person. That shapes what it is good at and what it is not, so it is worth saying plainly rather than leaving you to find out.
I wanted to see how a package of mine holds up once it’s published.
So I picked something big enough to find out: a form engine. Forms have enough real problems — validation, branching, steps, drafts, submission — that you can’t fake your way through them.
Somewhere in the middle I stopped writing things down. Coming back to it now, I spend more time relearning my own code than adding to it, which is why fixes and features have slowed. Documenting the decisions as I make them is the fix, and it is underway.
If you’re here from a CV or a link: the interesting part isn’t the marketing, it’s the code, the tests, and the parts I got wrong. Those are all in the repo.
Read the source →Mostly that shipping is the hard part.
The engine was the fun bit. Everything around it is where the actual lessons were.
A scoped npm org, four packages that depend on each other, build outputs that work in both ESM and CJS, and versions that don’t contradict one another. None of that is writing features.
1,270 tests weren’t for correctness so much as for me — they’re the only reason I can still change the engine after forgetting how it works.
Checking the schema at boot instead of trusting it at runtime removed a whole category of confusing bugs. Obvious afterwards; wasn’t obvious to me at the start.
The main thing I’d do differently. Undocumented decisions cost me more time than any bug did.
The scope is on the homepage.
What the library does and does not cover is listed there, in full, before you install anything.