Creating and using private npm modules across your team.

How to install npm using private Git Repos

Npm modules can be installed in a few different ways (https://docs.npmjs.com/cli/install), you can install them from a registry, tarball file or url, a local folder or finally a Git repo. In this case, I’ll be discussing using private Git repositories for use of a team to manage and install components across multiple projects.

Firstly, you’ll need to create a boilerplate for an npm module. This depends on the intended framework and is “out of scope” of this article (pun intended), however there is plenty out there so get Googling. We highly recommend using typescript, for all the reasons of it’s existence, it really comes in handy with updating shared components.

Once you have a boilerplate, you can use this base for your new component’s repos. Create a repo, get coding, create a version tag in Git and install.

Why you should do it.

Having components in their own repos and packaged as npm modules has many advantages;

When one member of your team fixes a bug or creates a feature in the component that may benefit other projects. Updating the other projects is as simple as updating the package.json and running yarn install. Of course if there’s breaking changes there might be some more updating to do, however this creates a consistent and efficient methodology to managing and updating components across projects. 

Components can be constantly improved by all team members, and can be kept up to date across projects with ease. Version control and pull requests on the repo are recommended to help the team agree on any updates. 

Semantic Versioning

Use semantic versioning (https://semver.org/). Versioning shouldn’t just be bumped when any change is thrown in. The version number needs to communicate to another team member if there are breaking changes, so they can choose whether or not it’s worth updating the component in their project. 

This methodology forces developers to be flexible, it’s no use having anything inflexible in shared components they’ll soon cause problems. It’s a new way of approaching and writing code and not suitable in some scenarios, however for shared components it’s worth spending the time on. 

Testing of the components functionality is made redundant in projects, as the testing for the component moves into its own repo. Decreasing the cumbersome testing, and increasing reliability.

When you shouldn’t use it

It’s time consuming, writing flexible code is a process that requires planning and forward thought about all of the scenarios it will be required to work. The first question should be, “should this be a shared component?”, or should this be unique to its codebase. This methodology can be too complex for some components and thus unsuitable, resulting in your team struggling to maintain the components.

For some frameworks things can get tricky when developing the components. For example React Native. Creating and testing the components in their own projects can be cumbersome at first. However the benefits can massively be worth the investment.

There are other options, you could use monorepos or existing services like Bit (https://docs.bit.dev/docs/quick-start). Monorepos have a reputation of being cumbersome, and in our opinion rightly so. Bit is a great service, although it’s not cheap.

In Conclusion

Harnessing private npm modules has worked amazingly at prism, they’ve improved efficiency in the long run and created a more consistent, efficient and reliable codebase overall that’s far easier and enjoyable to maintain. 

If you can’t tell, we’re sold on shared components via npm modules, we use them for Node, React and React Native frameworks.