I built a NPM package

I built a NPM package

TLDR: If you love developing software and something frustrates you, build a solution and maybe publish a NPM package :)

With approximately 2.7 million NPM packages already in existence, the creation of a new one may not seem groundbreaking. However, my intention with this article is not to tout novelty but to ignite inspiration.

My aim here is to encourage you, the reader, to ponder over the everyday challenges encountered in your professional or personal projects, and contemplate crafting a solution and releasing it to the developer community. If you've encountered a problem that does not have a solution, chances are, others have too.

In this article, I want to share with you my experience with building a NPM package. I want to share my inspiration and motivation that lead me to create a solution for developers to use.

Note: If you are developer that frequently contributes to open-source or builds packages for the public, this post is not for you.


At the time of writing this article, I have been in the software engineering world for about 6 years. During this time, I have primarily worked in the world of web development having built software for physicians, pharmacies, educators, and students using a plethora of tools, languages, framework, and libraries. So I like to think that by now, I know a thing or two about building software 😊

Imagine you are baking a cake, but instead of measuring out every ingredient and whipping up the batter from scratch, you stroll into the store and grab a ready-made cake mix. That is essentially what a JavaScript library isβ€”a pre-packaged bundle of code goodies that you can import into your project with a snap of your fingers (or a few lines of code). It's like having a magical recipe book full of solutions to common problems, from making your website sparkle with animations to handling complex data like a pro. So, instead of reinventing the wheel every time you face a coding conundrum, just reach for a library and let the coding fairy sprinkle some ready-to-use magic into your project! πŸ§™βœ¨

My inspiration for building a library came from a necessity at work. I am currently in the process of upgrading our codebase from Vue 2 to Vue 3 (Javascript front-end framework).

If you are not familiar with Vue, that is okay! Vue is web framework that allows Javascript developers to build front-end applications. If you heard about React or Angular or Svelte, Vue is one of them 😌

Internally, we use a library that allows us to use the same translation files for both our frontend and backend.

Translation files allow developers to define a key-value pair of objects that represent an action/label and its corresponding value for different locales. You can read more about it here.

The issue is, it is an important library that we need and the author had not released a Vue 3 compatible version. I had a few options - fork the repository or create a Vue plugin from scratch. I decided to pursue the latter and create the plugin from scratch and credit the original author.

What was the process?

Creating a package

Creating a package was simple with vue-create. Once a package.json file has been generate and the project has been scaffolded, you are good to go.

If you want to create your own Vue project, you can read more about it here.

Creating a plugin

Thanks to the comprehensive documentation, creating a plugin in Vue is a breeze! However, I will not go over the specifics of writing a plugin as it is not in the scope of this article.

If you are interested in learning how write your own Vue plugin, you can read more about it here.

I rewrote the plugin in Vue 3 and injected it into my Vue instance to provide app-level (global) access for any components.

Final touches

To deploy the package you need to give your package.json some information. I did not know about a lot of properties that a library author needs to declare. Some of the ones that I had to read up on were - module, main and exports.

Don't forget to ensure your Vite config is correct as well. After verifying these two files, it was time to publish to npm.

It is useful to create tags to ensure your releases are in-line with semantic versioning. Once your package has been deployed, that is it. The heavy lifting is actually in the final process but once you have deployed a few packages, this comes naturally.


I hope by now I have inspired you to start thinking about deploying that clever idea that you had saved on your local machine but were too afraid to deploy. The open-source community if a large world - there are always unknowns. But be BOLD, and take that leap. Learn from your experiences and considering sharing with the world.