Open source. Author. React 19, Tailwind, Radix, Framer Motion. Published on npm.
DesignSystem
A React design system following Apple human interface guidelines, shipped two ways at once: an npm package you depend on, and a registry CLI that copies components into your repo so you own them.
The problem
A design system has two failure modes. Ship it as a locked dependency and every team that needs one small change forks it or fights it. Ship it as copy-paste and there is no way to push a fix to anyone who already copied.
This one does both. It publishes as a versioned npm package, and it ships a CLI with its own registry so a component can be copied into a repository instead. The part that makes the second half work is that the CLI tracks what it wrote.
Own the component, still get the fix
Components copied in through the CLI stay editable in your repository, and the CLI can still tell you when the upstream version moved.
Updates you can undo
The CLI has add, init, status, update and rollback. An update that breaks a screen is reversible without a git archaeology session.
One constraint instead of taste
Apple human interface guidelines are the reference, so component decisions get resolved against a published standard rather than an argument.
Decisions and the price I paid for them
Ship as a package and as a registry
Teams that want a dependency get one; teams that need to own and edit the component copy it in. The same source produces both, so neither is the neglected path.
Trade-off accepted
Two distribution mechanisms to keep in step, and a registry build that has to run on every release.
The CLI tracks what it wrote
Copying a component is only safe if something remembers the version it came from. That record is what makes status and rollback possible at all.
Trade-off accepted
Extra state in the consuming repository, and a manual edit can drift from what the CLI thinks is there.
Radix underneath, Apple on top
Accessible primitives from Radix handle focus, keyboard and ARIA; the system layers Apple-style motion and surface on top rather than reimplementing behaviour.
Trade-off accepted
A Radix upgrade is a system-wide concern, and the primitives constrain how far a component can be restyled.