Advantages of reusable code

While working on a multi-module project, you probably noticed the need to separate some functionality to prevent code duplication. The main advantage of such a solution, apart from the above, is protection of the application against serious damage resulting from not introducing changes to one of the code duplications.There are many more advantages to reusable code, but that's not what I wanted to focus on in this article. There are a couple of options available that give us the ability to share code.

A range of possibilities

We can share the code by creating a separate project with the help of NPM or use the solutions provided by GIT. Here we have the option to move some code to another repository and implement a submodule. If we want to avoid creating a new repository, we can use the architectural pattern which is Monorepo.An additional possibility is given by perhaps a less known way of sharing components, which is BIT. As you can see, there are several possible solutions, but which will work best in a specific project? In the rest of the article, I will try to clearly present my observations on this topic.

GIT and submodules

The solution that allows you to extract reusable code without the need for additional tools is GIT and submodules. This is definitely an advantage of this solution, but if you want to clone the repository together with the submodules, you are forced to download the submodules separately. This involves taking additional steps to get started with the project.If upstream repository moves to a different location for some reason or is unreachable, the folders that should contain the contents of the submodules will remain empty after cloning. When using submodules, we must remember that if we make changes to a submodule, we are obliged to commit the changes in the parent repository.The disadvantage of using submodules is that archived repositories do not contain the sources of the submodules. This means that the archives are not self-contained. As you can see above, when using the submodules offered by GIT, we must remember about a few additional things, which in the case of multi-person teams may make it difficult to work on the project.There are tools available that are designed to provide additional automation for a submodule solution such as git-subtree or gitslave. However, these are not ideal solutions. For example, in the case of git-subtree, changes to the subtree clutter the history of the main project.

Alternative as Monoropo

An alternative solution is the Monorepo mentioned in the introduction. In this case, we work with one repository, which simplifies the management of dependencies in the code. The simplified code refactoring can also be considered an advantage of this approach. Instead of making changes to multiple repositories, we're doing it in one.All collaborators with access to the repository have access to all code. As a result, shared libraries are easier to find. This encourages collaboration and code reuse. But what if we wanted to restrict access to the code? There is a problem with access control. Additionally, it is problematic to isolate the code previously added to the repository and make it available for example as open source.A number of problems can also be encountered when preparing the deployment process of one of the projects included in the repository.

NPM and modularity

Another solution that is definitely worth considering are private modules created with the use of NPM. The initial configuration of such a solution seems to be a more complicated task than in the case of the submodules provided to us by GIT. However, later the use is much less problematic. Thanks to the multi-modularity used, we will not encounter the problems I mentioned when referring to the Monorepo pattern.

BIT and components

It is also worth mentioning the tool that is BIT. It offers the possibility of creating an application divided into components that we can share. The main difference compared to the solution offered by NPM is the ability to store the shared code together with the application codebase. With this approach, complications can arise if you need to remove a piece of shared code.

Summary

I hope that I was able to briefly and clearly present the advantages and disadvantages of individual solutions that I have noticed. It is impossible to make a decision to use a specific solution without knowing the assumptions about the project. I trust that a number of information contained in the article will make it easier to answer the question asked in the introduction to the article.Article written by Krzysztof