I have a strange confession to make. Until a few weeks ago, I'd never published an NPM package. If that doesn't sound all that strange to you, consider the following:

1. I've been primarily a frontend developer for the last 6-7 years.
   

2. As a JavaScript (React) dev, my life basically revolves around NPM. Every new project I start begins as a "package". Every legacy project I've worked on is a "package".
   

3. On some days, I'm less of a "programmer" and more of a "package manager". I install new packages. I uninstall orphaned packages. I upgrade existing packages.
   

4. As someone who's been doing dev for decades, the first, middle, and last thing you're ever taught is DRY. And in the world of frontend dev, one of the most obvious ways to not repeat yourself is to bundle your work into packages.
   

But with all that in mind, I had never actually published my own NPM package. The reason why is a bit convoluted. But if you're in the same boat, I'd like to share a few epiphanies I've had in the last month-or-so.

Packaging Obstacles

I spent the first few decades of my career working mostly on backend code. In fact, for a good portion of my career, there was no such thing as a "frontend dev".

If you're a "backend" kinda person, there are still ways to share / bundle / package code. But in my experience, those paths are fewer and harder to follow.

When I was doing PHP / ColdFusion / Perl, "packaging" your code basically meant copying-and-pasting it into some shared location. When I did C#, we had DLLs - but the vast majority of those were proprietary. When I did Java, it seemed that we pulled in a lot of 3rd-party packages - but there was no great central repository/directory in which we felt compelled to publish our own packages.

In fact, the whole idea of having a public programming profile often left me feeling snarky. Some recruiter would ask if I had a GitHub profile they could look through and I'd think, "Maybe I'll go post all of that proprietary, highly-sensitive, corporate-protected IP that I've been working on. I'm sure no one will mind."

Doing primarily-backend code made public packaging seem highly impractical. The technologies I was using made rampant code-sharing feel awkward. And the nature of the work I was doing made me sometimes fear the idea that I'd publicly post anything at all.

The Sharing Paradigm

Sharing code isn't confined to the world of frontend development. But I believe that the NPM ecosphere makes it far more accepted. When I was doing C# work, if I walked in with a handful of DLLs that I downloaded from the internet, and I now wanted to incorporate them into the organization's app, I'd get a lot of flak over the idea. But when you suggest that your JavaScript project might need a new/different NPM package, there's typically far less scrutiny. In the JS universe, this kinda thing is just considered to be more "normal".

Please note: I'm not claiming that using NPM packages is devoid of its own scrutiny. Depending on what kind of app you're working on, and what kind of company you work for, adding NPM packages (or even updating existing ones) can be a major PITA. But I still think it's easier in, say, your average React shop to consider adding/updating packages, than it is in, say, your average .NET shop.

Still, I haven't started creating NPM packages because I suddenly grew concerned about my karmic footprint in the software world. I got here because it's simply the most practical solution to a handful of key issues. Primarily, I've been in a phase lately where me-and-my-team have been spinning up multiple projects. Every time we spin up another project, I start the process by pulling over all of our "core" functions / Hooks / utilities / whatever. And when I say that I "pull them over", what I'm really saying is that I copy-and-paste them from a previous project into a new one.

I hope I don't have to explain to you the kinds of problems this can create. And yet, it still took me a long while before I finally thought, "Maybe I should put these in an NPM package??" I finally got tired of worrying about the mental baggage that occurs when you have a dozen slightly different versions of a given utility package floating around a dozen different applications. I finally concluded that all of these apps should be sharing the same code.

A Freeing Feeling

Once I finally took the dive and started creating NPM packages, I was kinda surprised by just how much utility code I've been hauling around with me from project-to-project. Obviously, you don't want to create an NPM package out of your app's core functionality - the features that distinguish it from any other app. But once you get outside of the core features, there's just sooooo much code that's... "generic". And IMHO, nearly all of that code is a candidate to be packaged.

Of course, you don't have to do this with NPM. You can directly define a GitHub repo as being a dependency in your package.json, and that's not a bad way to share your code. But I honestly think there are some key benefits to making it a formal package (that I'll discuss in a minute). And your NPM packages needn't be public (although I think there are also benefits to public packages, that I'll discuss in a minute).

The whole process of packaging my utility code has honestly felt rather... freeing. To me, one of the most powerful allures of coding is that we can, in theory, solve a problem once - and then never have to solve that problem again. And yet, when faced with the constraints of dealing with corporate codebases, I frequently found myself "solving" the same problem over, and over, and over again.

But converting stuff into packages feels like more of a "true" DRY solution. I write the code. I publish the package. I consume the package from multiple projects. And, if necessary, I fix/expand the project from one single repository.

Packaging Can Make Your Code More Rigorous

I've noticed a positive side effect of creating NPM packages: I'm more rigorous about writing - and checking - my utilities. Allow me to explain:

Maybe I have some simple function that just generates a random ID. I've used that functions hundreds of times - across dozens of codebases. So do I create unit tests every time I copy that function into a new codebase? Nawwww. Probably not.

But if I'm going to convert that function into an NPM package - a public package - I feel a greater compunction to add the appropriate test coverage. And when I do that, you know what?? Sometimes, I realize that there were a few edge-case flaws in my function. They probably never came up in the apps where I used the function - but they were flaws nonetheless.

Building A Legacy

The last "benefit" of NPM packages could be completely in my head. But it's kinda nice to think that, over time, I'll have this ever growing "legacy" of public software. It doesn't matter if most of that "software" consists of super-simplistic utility functions. It's just nice to think that, at some point, I'll be able to say, "Well... here are the 100 NPM packages that I maintain."

Granted, this isn't the only way to have a "legacy". Just having a GitHub account with a few public repos will also serve this purpose. Nevertheless, it's kinda cool to see when people are downloading your NPM packages - something that I've noticed happens far less frequently when the code is just contained in a public GitHub repo.

Conclusion

Obviously, publishing a few NPM packages doesn't magically make you a better dev. But... it certainly doesn't hurt. And now that I've finally waded into the process, I really think it's something that every "frontend dev" should try - or at least, become acquainted with.