// the find
hasanharman/form-builder
A dynamic form-building tool that allows users to create, customize, and validate forms seamlessly within web applications.
A drag-and-drop form builder for Next.js that generates working React Hook Form or TanStack Form code wired to Zod validation, plus a shadcn registry of extra field components (phone input, signature pad, credit card, tree-select, etc.). For developers already in the shadcn/Tailwind ecosystem who want to skip hand-writing form boilerplate.
Generates code for two different form libraries from the same builder UI, and the output starts with the exact `shadcn add` command for the fields actually used, so you're not guessing which dependencies to install. The registry components are built against props every shadcn style shares, so the same phone-input or signature-pad installs into Radix (`new-york`) and Base UI (`base-*`) projects alike - and there's a real test for it (registry-catalog.spec.ts checks declared registry deps against actual imports, not just a README claim). It also has unit tests around the code-generation logic itself (form-code.spec.ts, field-variants.spec.ts), which is the part most likely to silently break, rather than just UI snapshot tests.
No backend story at all - the README's 'API' section is a toy fetch() call, so file uploads, server-side validation reuse, and persisting submissions are entirely on the adopter. components.json targets a Base UI style (base-vega) while CONTEXT.md and .migration/project.md point to an in-progress Radix-to-Base-UI migration, meaning anyone pulling registry components in now is building on a UI foundation that's still moving. There's heavy duplication across components/ui and components/components - credit-card, signature-pad, phone-input, and others each exist as two near-parallel implementations, which is extra surface area to keep in sync mid-migration. No accessibility testing shows up anywhere in the suite or docs, which is a real gap for a tool whose whole output is forms, where dynamic validation errors and custom controls like token-input or cron-expression-builder are exactly where screen-reader support tends to break first.