When we have multiple projects using similar code, there is an urge to publish them as NPM packages. Should we publish them as public NPM packages or private NPM packages which can be used only within our enterprise? Or when should we avoid publishing a NPM package?
Let’s assume we have this question for UI projects. Most UI projects run on the browser. The bundle size is a constraint. We cannot have too large a bundle size since it directly affects performance of our app. So, let’s look at the different scenarios when we want to publish our code as NPM packages.
Reusable code
Reusable code is a candidate for NPM packages. But should they make it to the public NPM registry? In my opinion, 99% of the time, our code is not a candidate for public NPM registry. For a package to be public, it should take care of many scenarios. If our package is very generic, then it has some extra code for all the scenarios. We won’t use any of the other scenarios. So, why write the code? If we write some code and publish to public NPM repository, we have to maintain the code, especially when someone opens an issue.
So, should we publish the reusable code to a private NPM repository? Yes, provided there are multiple projects using that code. Private NPM repository costs some money, around $9 /mo. With private NPM repository, we do not have to worry about the additional scenarios which we won’t need. But have our source code in NPM packages which are shared across projects.
Customization
Let’s say, we have reusable code. But that package is prone to lot of changes in code. And as time progresses, there is a lot of divergence in the features needed for each project using that package, then it makes sense to keep the source code within the individual projects without publishing to NPM registry.
If your project always goes for generic features, your app will look similar to many other apps, and there is no room for UX innovation. So, having highly specialised and custom components is what makes your app remarkable. For making remarkable apps, build specialised components. And in this scenario, you won’t need to publish to any NPM registry – public or private.
Testability
When we publish to NPM registry – public or private, we need to write tests along with it. If there are no tests, then the whole purpose of publishing a NPM package is defeated. If there is no time to write tests, then don’t publish the package to NPM.
Styles
For UI components, styles are another concern. You may be using SASS or LESS or something like styled components. Styles can go into packages. But if you want real customisation for the end user, we have to write a lot of class names. Which might lead to some sort of code bloat and unnecessary code maintenance. For example, you may have a class defined and later want to remove it. But since these classnames are public, it is equivalent to a breaking change. If you want to avoid the additional cost of style maintenance, it is better not to publish to NPM registry.
Code Bloat
Publishing to NPM registry often leads to code bloat. Code which we cannot remove because someone may be using it. But is no more relevant for our project. To avoid code bloat, think twice before publishing a package to NPM registry – public or private.
Summary
Publishing a NPM package to the NPM registry seems like an easy choice when we have reusable code. But it is not so easy if you consider things like code bloat and maintenance. Publishing to a larger audience restricts our freedom while dealing with code changes.
Often, our project needs to be remarkable by having highly specialised UI. So, the generic packages available in NPM registry won’t do. But that does not mean we have to publish our own packages. Think twice before publishing a NPM package.
If you are creating a commodity backend app which just needs some simple UI, go ahead and use standard NPM packages available. Even with this scenario, there is no point publishing your own NPM packages. Just use already existing packages like antd, bootstrap or material UI.