How To “Publish” Multiple Packages From Any Repository In 5 Minutes

March 05, 2018 0 Comments

How To “Publish” Multiple Packages From Any Repository In 5 Minutes

 

 

How to make any part of any repo available as a package with NPM in 5 minutes without splitting or restructuring your project, and how to easily make changes to these packages from any other project with Bit.

Making any part of your code instantly available with NPM

While packages are great for modularity, having to split your codebase just to publish them requires a lot of overhead, making it hard even at a small scale.

So does the overhead of boiler-plating the configurations needed for these packages, and the ongoing process of making changes across different repos.

Refactoring your project’s codebase into a multi-package “monorepo” also comes with an overhead, and in the end still forces you to manually define the build configurations and dependency trees for all these packages.

In both cases, to make changes to these packages you will still have to go through the original repository and its owners.

Bit works with Git and NPM to help you create multiple packages from any existing repository, without splitting it, changing it or having to configure dependency trees and build processes just to publish them.

Then, it also lets you make changes to these packages from any other repository or project in your codebase. Let’s see how.

Using Bit you can easily isolate any part of any existing repository without changing it at all, so you can then use this code from other projects.

Bit helps you isolate parts of existing projects

Let’s take the following project’s structure as an example.

$ tree
.
├── App.js
├── App.test.js
├── favicon.ico
├── index.js
└── src
└── components
├── button
│ ├── Button.js
│ ├── Button.spec.js
│ └── index.js
├── login
│ ├── Login.js
│ ├── Login.spec.js
│ └── index.js
└── logo
├── Logo.js
├── Logo.spec.js
└── index.js

5 directories, 13 files

In this repo, we have 3 components we would like to use in other projects as NPM packages: the button, login and logo components.

Normally, we would have to create a new repo for each of them. Inside each repo, we would have to boilerplate and configure the package’s boilerplate.

With Bit, we can simply isolate these parts from the repository’s existing structure and make them available with NPM from other projects.

First, let’s install Bit.

$ npm install bit-bin -g

Then, we can initialize it for the project we want to share from.

$ cd project-directory
$ bit init

If needed, let’s add build and test environments to save the overhead of configuring a package. Here is an example for some React components.

$ bit import bit.envs/compilers/react --compiler
the following component environments were installed
- bit.envs/compilers/react@0.0.7
$ bit import bit.envs/testers/jest --tester
the following component environments were installed
- bit.envs/testers/jest@0.0.7

Now let’s tell Bit which parts of our project we would like to isolate. You can also specify the test files for your components in the bit add command, but for now let’s keep it simple.

# use a glob pattern to track multiple components in the same path, or a single path to track a single component.
$ bit add src/components/*

Finally, let’s lock a version and let Bit define the dependency tree (both internal files and external packages) for the code we want to share.

$ bit tag --all 1.0.0
3 components tagged | 3 added, 0 changed, 0 auto-tagged
added components: components/button@1.0.0, components/login@1.0.0, components/logo@1.0.0

That’s it.

Bit now track these files within the project, resolved their dependency tree, locked a version and prepared an environment to build and test them.

We can run a quickbit status command to see which components were isolated and are ready to be shared.

The great thing is, our project didn’t even change one bit (pun intended).

Sharing our code to the cloud with Bit

This part is even simpler.

Unlike NPM, Bit doesn’t force you to actually create the package before you share it. Meaning, Bit will do it for you once it’s shared — on the cloud.

To make the code we just isolated available as packages with NPM all we have to do is share it to Bit’s open registry.

All we have to do is create a Scope, which is a workspace to organize and host the code we share, from which it can also be installed using NPM.

Let’s share the 3 isolated components to a Scope.

$ bit export username.scopename  
exported 3 components to scope username.scopename

That’s it. Every one of these components can now be installed from the Hub using your favorite package managers!

Here is an example React project and a matching Scope, so you can get a better idea of how it really looks.

Note that the repo didn’t change at all! We didn’t have to split our project, create new repos for our packages or refactor our existing code. Effectively, we turned our repo into a multi-package “monorepo” without changing it.

Easily make changes to your packages from any of your projects

Now comes the really cool and awesome part.

Bit provides a feature we like to call “managed copy-pasting”, which basically lets you make and sync changes to the shared code from any other project.

Instead of going through the owner of the original repo of the packages, you can simply bit import the actual source code into any of your projects, make changes, and share them back out to your Scope!

Here is how it works.

First, we’ll need to bit init Bit for the new projects and then bit import the code we shared. This will enable us to make changes to this package from the consuming projects, instead of from the original one.

# 1. init Bit for the project
$ cd project-directory
$ bit init
# 2. bring the component's source code into your project
$ bit import ownername.scopename/namespace/component-name

Now we can make all the changes we want (a rare YOLO moment).

Now let’s compile the new code and run the project.

$ bit build
$ npm start

We can now bit tag the code again to lock a version and resolve depndencies, and simply share it back to our Scope (bumping a version) or into a new Scope -it’s our choice.

# tag a new version of the modified components
bit tag -am "YOLO changes"
# export back
bit export ownername.scopename

When sharing, you can even eject the code back to being a package dependency when exporting it again using the --eject flag.

You can learn more about updating changes here.

In about 5 minutes we were able to make multiple parts within our existing repository available as packages with NPM.

We didn’t have to split our project, set up new repos or work hard to boilerplate the configurations for any of these packages.

Instead, we were able to isolate parts of our existing repository with all their dependancies, add build and test environments (you can even create your own envs) and make these parts available as packages with NPM.

To change the code from any other project, we simply imported it into a different project, changed it, and let bit sync the changes for us.

During this workflow we also ended-up having an organized catalogue of all our team’s reusbale components, on which we can now work together and collaborate through the cloud.

This workflow means Bit enables scalable code sharing between repos and project, helps avoid duplicate code, prevents the pains of growing more repos to maintain in our codebase and makes it easy to find and use our best code.

Feel free to get started, suggest feedback or contribute to Bit on GitHub!


Tag cloud