Monorepo in action for library maintenance 💞
In this post, I would like to share my experience of maintaining a couple of libraries using the monorepo approach. Stay tuned and read on guys 😊
I have been developing a couple of UI libraries lately as below:
- Zoom Image - A little yet powerful framework agnostic library to zoom image on the web
- Headless Playback - A little yet powerful framework-agnostic library for playback experience
- Social Player - A simple yet powerful library to playback social media for the web
The original inspiration came from fantastic Tanstack and Zag libraries. These two have set great examples of how UI libraries should be authored in modern web development. As of writing, the web frameworks healthy competition is still going on among React, Vue, Svelte, Solid, Qwik, Angular, et cetera. It is not uncommon that someone from the X framework to try to achieve something similar in the Y ecosystem. For instance, when working in React and dealing with media players, developers can easily come across React Player library while it's not the case for other developers from the rest of frameworks. This is exactly why I strongly believe the future of library maintenance should be framework-agnostic, because it is web development and it will compile down to just HTML, CSS, and JavaScript eventually. We should start from vanilla, raw web technologies before expanding to other frameworks via adapter pattern
The above section was describing WHY we should govern web libraries in a framework-agnostic way. Next, we need to discuss WHAT and HOW to achieve them in maintainable ways. This is exactly where modern tools shine in practice. Let's list down all problems we need to solve with framework agnostic library and how to solve them with the help of modern tooling libraries:
- We need a single repository to host our solution, and share code among core library code and adapters - Monorepo is designed exactly for this purpose. Please feel free to have a deep dive into the linked post to discover more about monorepo if you haven't heard of it 🙂
- Package installation with monorepo support - all modern JavaScript packaging tools do have support for monorepo via workspaces. I highly recommend PNPM because it is fast, efficient and well-maintained
- Package release - I chose to use changesets since it is widely used by famous libraries and has dedicated support for monorepo. It also helps you to prepare release notes effectively
- Build system - building linked packages at scale can be very tricky and easily slow you down at scale. Yet, thanks to tools like Turborepo and Nx, it is no longer the case as everything will be analyzed and computed smartly on demand. In return, it will save you more time from waiting on building, revalidating, linting, caching, et cetera for the actual development of your dream libraries
- Demo examples - Vite has become a de-facto industry standard for modern front-end tooling. I have used it for years without any regrets. I have used it to power all examples for framework adapters like Vanilla, Vue, React, Preact, Svelte, Qwik, and Solid
- Documentation - Vitepress has become my favourite choice for documenting library usage lately thanks to its speed, ease of use, simplicity, and vast ecosystem around it. It even has built-in support for the Algolia search.
There you have it guys, my personal experience on how I chose monorepo for developing and maintaining libraries in action. Hopefully, you found it useful, and will help you in choosing the best approach for your next wonderful project. Peace out and until next time 💞