I finally made Glyph UI Alpha Version 0.1.0-alpha.2 live.
And before I talk about Glyph UI, I need to admit something that is slightly embarrassing.
I've been a web developer for 10 years (2016–2026), and I've never published an npm package.
Not one.
I've used hundreds of them. Installed them, updated them, removed them, audited them, and occasionally spent an unreasonable amount of time trying to figure out why one dependency broke another.
But publishing?
Never.
So when I finally decided to publish Glyph UI, I discovered something interesting:
Knowing how to use npm and knowing how to publish to npm are two very different things.
And I learned that the hard way.
36 Packages. What Could Go Wrong?
Glyph UI Alpha currently has 36 packages.
I had my publishing script ready, everything was built, and I started publishing.
I got 25 packages live.
Then npm basically told me:
"You've had enough."
I hit the publishing rate limit.
So my release process immediately became:
Publish → wait → publish → wait.
I ended up waiting around 48 hours before I could continue.
At this point, I thought I'd learned my lesson.
I had not.
Then I Found a CSS Bug
Two of the packages had a CSS bug.
My immediate thought was:
"No problem. I'll just remove them and publish them again."
That was a great idea.
Except it wasn't.
This was when I properly learned that published npm versions aren't something you casually replace whenever you find a problem. The normal approach is to publish a new version with the fix.
Since Glyph UI has 36 packages and I wanted to keep things consistent, fixing those packages also meant dealing with versioning across the project.
So I had more packages to publish.
And what did more publishing mean?
The rate limit was waiting for me.
This little CSS bug ended up costing me another 4–5 days of release work and waiting.
For two CSS files.
Beautiful.
The Part I Completely Underestimated
The actual components weren't the difficult part.
I'd already spent the time building Glyph UI, moving it to Tailwind v4, working on the components, documentation, and everything else that comes with building a UI library.
What I hadn't properly considered was the distribution side.
When you're building an application, you fix the code and deploy again.
When you're publishing packages, the release itself becomes part of the engineering problem.
Suddenly I had to think about:
- package versions
- dependencies and peer dependencies
- build output
- CSS
- package exports
- release scripts
- publishing limits
- and making sure consumers actually receive what I tested locally
That's something I simply hadn't experienced before.
What I Should Have Done
If I could go back and do the first release again, I'd do a few things differently.
I'd test the publishing workflow with a small number of packages first.
I'd test the actual packed npm artifact, not just the development build.
I'd verify the generated CSS in a clean project.
And I'd design the versioning and release process before trying to publish 36 packages at once.
Basically, I should have treated npm publishing as part of the project instead of the final button I press after the project is finished.
Anyway, It's Live
Despite my excellent decision-making, Glyph UI Alpha Version 0.1.0-alpha.2 is now live. You can try it here:
Live: https://glyph-ui-alpha.vercel.app/
It's an Alpha, so expect things to change. I'm still working on it and figuring out what needs improvement.
If you try it, I'd really appreciate feedback—especially if something breaks.
Feedback: https://github.com/kaustubhdevstack/glyph-ui-alpha/discussions/1
And yes, I know this entire story could have been avoided by learning npm publishing beforehand.
But then I wouldn't have a story to write.
After 10 years of consuming npm packages, I'm finally on the other side.
I make the package now.
Let's see how badly I can mess up the Beta.
