Things I learned while building my JS library

If you call yourself a developer, and you haven’t created any library or thought about building one, my friend you haven’t scratched the surface of being a developer.

While working on a personal project or in your company, you must have thought about making a library around those functions or components you are building repeatedly. And it makes sense too, according to the DRY (Don’t Repeat Yourself) principle. But a lot of effort goes into making something that is useful and others also can use.

And building a library is not just about, bundling some functions or components together which are flexible and dynamic. There is a lot of thought goes into it like

• API – Simple and easy-to-use functions, with IntelliSense in the editor
• Bundling – Getting everything together into a single package or multiple packages, which can be easily used by you and your team.
• Versioning – Tools to release and version your packages
• Testing – Checking if there are any breaking changes and the application is working correctly. Maybe you can have a test app, where you deploy the changes to check if everything is working before releasing a new version. Or simply a jest or playwright test to check them in a CI/CD workflow through automation.

And then in the JS world, you also have to figure out things like

• tree-shaking
• side effects
• ESM or CJS
• code splitting
• bundling dependencies
• dev dependencies
• peer dependencies
• exports
• modules
• types (.d.ts files)
• JS Docs or TS Docs
• and many more…

These might look overwhelming to you but knowing these things is crucial for your career and in general as a developer. I will not go in-depth about what these things are in this article, maybe in the future but there are plenty of amazing articles about these on the internet.

However, all of these problems can be resolved with a bundling tool like, Rollup, Vite, and Webpack. Knowing what configuration will be required and how things will be working is the hard part. As that is the main thing, Nextjs uses Webpack, pre-configured to handle all of the bundling of their application, so that you won’t have to.

Lately, they are also working on a new bundling tool, Turbopack which is written in Rust and I think they are claiming that it’s backward compatible with Webpack but still, it’s in alpha, so we will have to see. Vite is also working on Rolldown, a Rust-based version of Rollup. These updates and changes will not make sense to you as long as you are in the ecosystem.

As a JS Developer or any developer, you should know how to an environment without the need for any setup tools. As these tools are great for starting a new project but as soon as you will require something outside of this ecosystem, you are stuck.

Solving leet code questions, or any sort of competitive questions helps you to understand the core coding concepts. But building a library, and iterating over it helps you understand the concepts of your programming language, because different languages may have the same keywords or functions like while loop, for loop, variable declarations, and others. But their inner workings and performance will differ and this is how you become an expert in that language, by knowing these things. So that you can already see where your functions or applications might suffer in speed or performance.

This is true for any programming language, not just JS. The best part is, that you start to get familiar with all the tools and are more comfortable while using them. Making you faster and more efficient in building applications.

Building a production application or library is not easy. And the learning you get while building them on your own is far more than just watching it on Youtube or following a tutorial.

And I also, as an experienced developer have messed up a lot. Sometimes there were config errors and bugs in general, proper testing was not done before deployment, documentation website was not working properly. If the library has integration capabilities then, that might not be working properly, and the list goes on and on.

The thing is mistake happens, and that is what the learning is so that next time it doesn’t happen. If you are using tools like nextjs or nuxtjs, then you need to build things like this. Because these tools are built to help developers build applications rather than stuck in setting things up, like Rollup or Webpack configs. Yes, these tools are amazing and do most of the stuff for you but big production applications are not just nextjs or nuxtjs, they comprise a lot of small/medium-sized libraries and applications built on Python (for AI maybe) and just React (Admin Panel). Then the need for a monorepo arises but you might not know what a monorepo is, because you have never come out of these ecosystems.

You can refer to this article, Things I Learned While Building My Component Library, where I have gone into more detail about the tools and libraries that my team and I use to build applications.

Conclusion

I learned a lot. From building better APIs and functions to libraries and publishing them on npm. It took me 6 months to complete all of this. And yes I know this sounds like a lot of time, but I had my fun. Building this gave me insight into what goes into building a library which others can also use and cherish.

I would say that if you haven’t ever built a library, you should at least try to. The community is a great help, if you are stuck somewhere, some people can help you or also have fallen into the same problems, on which you can build.

Github, StackOverflow, and other online forms are great places to seek help and guidance related to your problems.

If you want to check out my lib from which I got all my learnings, here are the links –

@rafty/ui

GitHub – github.com/rhinobase/raftyui
Docs – rafty.rhinobase.io

Do let me know what you think about it and how we can boost the community in the future. Do show us your support by giving us a star and for more content like this in the future.