I Spent More Than 10 Hours Diagnosing My Code. The Bug Wasn’t in My Code.

I Spent More Than 10 Hours Diagnosing My Code. The Bug Wasn’t in My Code.

Building Kivex Solid taught me that sometimes the hardest bugs are hiding in the tools you trust the most.

I spent more than 10 hours diagnosing my code yesterday. I started at 12:00 PM and didn’t finish until about 4:00 AM the next day.

Although… I had a lot of breaks in between.

At first, I thought the problem was with my icon generator. Then I suspected my exports. After that, I checked my package structure, my TypeScript configuration, my workspace setup, and even my IconBase component. Every test seemed to point in a different direction, and for hours, nothing made sense.

The frustrating part was that direct imports worked perfectly, but importing from my package’s main entry caused the entire page to go blank without any useful error.

It felt like I was chasing a ghost.

What made the experience even more interesting was what I was actually building.

A few weeks ago, I wrote about my first open source contribution, where I built Kivex React, a React wrapper for the Kivex icon library. At the end of that article, I mentioned that my next task would be building Kivex Solid.

I’m happy to say I succeeded.

Kivex Solid is a SolidJS wrapper for the Kivex icon library, allowing SolidJS developers to import and use Kivex icons as reusable Solid components with proper TypeScript support.

Having already built Kivex React, I approached this package with much more confidence. I already understood the project architecture, the code generation process, and the overall vision behind the Kivex ecosystem. This time, I wasn’t just trying to make it work. I was also thinking about improving the architecture and creating a better developer experience.

Everything appeared to be working.

The components were generated correctly.

The package built successfully.

The source code looked clean.

Yet the icons refused to render.

For hours, I kept looking at my code because I was convinced the mistake had to be mine. I compared generated files, reviewed my exports, inspected every component, and questioned almost every decision I had made.

Nothing explained why the package worked in one scenario but completely failed in another.

After digging through the compiled output, I finally noticed something that changed everything.

My build tool was compiling my Solid components into React-style output.

At different points, it generated jsx/jsxs runtime calls and even React.createElement(), which explained why the package failed even though my source code was completely correct.

That moment changed the entire direction of my debugging.

The solution wasn’t rewriting my components.

It wasn’t changing my generator.

It wasn’t redesigning my package structure.

The solution was replacing the build pipeline.

I switched from Tsup to Vite with vite-plugin-solid, and immediately the compiled output became proper Solid code.

Everything worked exactly as expected.

That moment reminded me of something I don’t think I’ll forget anytime soon.

Sometimes the bug isn’t in your code.

Sometimes it lives in your tooling.

As developers, it’s easy to assume that if something isn’t working, the implementation must be wrong. This experience reminded me that software development is much bigger than the code we write. The compiler, the bundler, the runtime, and the build configuration all play an important role in the final result.

When you’ve exhausted the obvious possibilities, don’t be afraid to question the tools themselves.

Looking back, those hours weren’t wasted.

They taught me how to investigate problems more methodically, how to trust evidence instead of assumptions, and how to look beyond the source code when debugging complex issues.

More importantly, they led to a successful outcome.

Today, Kivex Solid is complete.

The package is working exactly as intended, and SolidJS developers can now use Kivex icons as reusable components in their projects.

It was a long day, and an even longer night.

Every minute was worth it.

Every difficult bug leaves behind a lesson, and this one reminded me that becoming a better engineer isn’t just about writing better code. Sometimes it’s about learning where not to look, so you can finally discover where the real problem has been all along.

Now, it’s time to keep building.