Latest news about Bitcoin and all cryptocurrencies. Your daily crypto news habit.
Between multiple repositories, mororepos and micro-services the discussion about sharing common code between projects is increasingly raging.
Sharing common code between projects and repositories is a key factor for better modularity and faster development, but it’s also complicated. I’ve written about it before, sharing from our own experience as a team.
Here is a practical overview of 5 methods for sharing code between these repos and projects for 2018. Just remember, down the line it’s really all about communication between people, culture and keeping modularity in mind.
1. NPM with and without Lerna
The prominent advantage of micro-packages is that they help prevent duplications and increases reuse and modularity. This led open source authors such as Sindre Sorhus to publish over 1,000 modules to NPM.
Sindre Sorhus with 1000 NPM packagesDan Abramov favors many modules
While micro-packages are great for modularity they also come with a major downside: overhead.
The overhead of having to create and maintain a new repo for the package, configure environments, publish it, change your original project’s source code and so on is dramatic. At scale creating an army of 500 or even 100 packages is enough work for a small team for months on end.
Even then, who’s to say which packages exist at our disposal? who knows how to search, find and decide which packages to use? discoverability is a major issue when it comes to small packages as Rollup’s author Rich Harris wrote:
“Many blog posts — scratch that, entire websites — have been created to try and mitigate the difficulty of finding what you need on npm…”
Even after finding a small package you might want to use, making the right choice is just as big of an issue:
“It’s up to you to evaluate the library: does it have tests? Can you understand the source code? Is it actively maintained? Is the documentation easy to find and consult?”
Together with the overhead of keeping hundreds of repos, and the difficulty (and ownership issues) of updating the packages through those hundreds of repos, this solution might be deemed unpractical for most teams. And let’s not forget about left-pad.
LernaThe Hydra from Lerna: Looking at its tail, I think it’s about to fall down
Lerna helps you to keep and configure multiple packages in a single repository. It can help mitigate the pain of different repos for different packages, and help build and test the project as a whole. This way, you don’t have to keep and maintain separate repos for different packages.
However, it still requires that you effectively keep multiple packages in a single repo with multiple package.json files, configure multiple build and test environments and create a dependency tree between them if needed. Updating these packages must also go through the main repo, making it harder to change these package from different projects.
2. Bit with NPM and Yarn
Bit speeds code sharing by combining the advantages of copy pasting and managed packages. Meaning, you can easily track changes to shared across your codebase wether it’s sourced in different projects or installed as packages.
It also eliminates the overhead for sharing code in the first place.
Splitting exiting repositories or configuring multiple packages in a single repo requires a lot of overhead just to share code.
With Bit you don’t have to split your repo in order to make part of it available as a package. Instead, you can share code directly from any existing repository without having to create new repositories or boilerplate packages within it.
You can use Bit to track code you would like to share from your repository, automatically isolate it (Bit will define its dependency tree) and easily share it to a remote shared location. This will not change your existing project’s code.
From there, it can be installed using NPM or Yarn in any of your projects. You can also use Bit to import the actual source code into more projects in a distributed workflow, and let it track changes across your codebase for you.
Bit’s Ran Mizrahi talking at @WalmartLabs
This means Bit effectively kills the overhead of sharing code, while providing enhanced discoverability and control.
- You don’t have to split repos to shared code or boilerplate multiple packages in the same repo. Instead, you can share parts of your existing projects and install them with your favorite package managers.
- You can easily change the shared code from any project by importing its source code, editing it, and sharing back out (you can also eject it to become a package dependency for your project). Bit will track changes and update them between your projects if needed.
- Discoverability is improved with an organized Scope, useful information (build and test results, auto-parsed docs etc) and a search engine.
- Bit will also take care of building and testing your components in an isolated environment so you don’t have to configure these setups in your actual repo. You also don’t have to keep multiple package.json files.
The “downside” of Bit is that in order to install with NPM and Yarn you will have to configure the open Bit hub as a Scoped registry to your native NPM / Yarn client using a simple command.
Here is an example react app and its matching Scope, and here is a short video demo with React (which was released before the NPM install workflow was added, but gives the basic idea).
3. Shared and common libraries
The advantage of shared-libs is that you keep all your shared code in one repo, which is easier to maintain and distribute than multiple micro-packages. However, unlike Lerna, they will be consumed as a single package.
Keeping all your shared code in one repo forces users to add the entire library to their project with redundant code, dependencies, complexity and weight, all to use a single component.
A React MaterialUI button component — do I really need a whole library?
It also makes the process of updates and modification very cumbersome, as every change requires the owner of the project to update the package. This can impair the adoption of these libraries within organization. Discoverability for different components within the library is also an issue.
These problems led communities such as Lodash to work long and hard in order to publish their components as individual packages to NPM. Google’s Polymer project (by Eric Bidelman and other OSS wizards) also keeps over 100 web elements in over different 100 repositories.
Note:
Lerna can be used to separate components within the library into packages within the repo. Bit can be used to share components from existing libraries.
4. Git sub-modules
Git is the SCM of choice for most dev-teams. It allows you to put one repository as a subdirectory of another repository, creating a single working-tree for the entire project, and one project can use code from another project.
Lessons learned in the trenches?
There are various problems with Git’s submodules. First, they only work on master branch. Second, submodules create highly coupled code between the various projects and make it hard to merge and collaborate on cross-repo tasks. A submodule repo also has no idea that it is nested, and might have a dependent repo.
There are various tools that provide additional automation around the Submodule feature, such as git-subtree, gitslave, braid and giternal. These tools try to improve some of the usability issues of Submodules, but are not supported by a specific vendor and have different drawbacks.
5. Copy-pasting code
Because let’s face it, what did future me ever do for me?When your teammate yells YOLO and goes rouge
To be honest, it is perhaps the most commonly used practice for code “reuse” on earth. I’d like to think that in most cases it’s the result of the lack of a “cheap” effective alternative and somewhat chaotic delivery cycles.
The problem is, code duplications are not cheap at all. Far from it.
A classic problem for future me.
Duplications are an ever-growing debt in your code base. You will quickly lose control, making maintenance a nightmare and delivery cycles ever longer. Many problems will only be discovered after delivered to production.
A recent study found that half the code on GitHub is duplicated. Our research found that a Javascript function like is-string was duplicated over 1,000 duplications of 100 different implementations in only 10k GitHub repos.
Think about the new features that could have been written if more people would share code, rather than duplicate or reimplement it. Think about the costs of maintenance and long delivery cycles for your organization.
Sharing code is about people
Each project and every developer has their own set of concerns, tools and workflows. Still, sharing code is the key to true modularity, which becomes increasingly popular in todays’s ecosystem and provides great advantages.
We chose to build Bit. No matter what method and tooling you choose, it’s important to encourage a culture that breeds sharing and collaboration.
After all, sharing between projects starts with sharing between people.
5 Practical Ways To Share Code: From NPM to Lerna And Bit was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.
Disclaimer
The views and opinions expressed in this article are solely those of the authors and do not reflect the views of Bitcoin Insider. Every investment and trading move involves risk - this is especially true for cryptocurrencies given their volatility. We strongly advise our readers to conduct their own research when making a decision.