CODEWITHSUNDEEP
javascripttypescriptrepositoryversioningmonolithic
ch0m4
ch0m4

Reputation: 11

Manage library version on multiple repositories

Hi friends :) I could use a little help on the problem we're facing at work right now.

Context:

Imagine you have an internal library named Toolkit 1.0. This library exports a lot of Types for your typescript projects (A,B,C).

On normal scenarios, all project are building fine and working perfectly!

The problem comes when John (fictitious name) is working on Project A and needs to update some Type; John then pushes a new version, making Toolkit 2.0. Without knowing Project B also used that type, John upgraded only Project A yarn lock;

Meg (also a character) comes into play a few days later, this time working on Project B, note that it is using Toolkit 1.0 at this moment, and she has to make a few more Type changes on Toolkit making it 3.0. When she updates her Project B local files, because of John changes, local build may correctly start to fail.

I feel like I don't have enough experience to understand this as a whole yet.

Fortunately, this is not a frequent scenario, but we've started to discuss this lately as the team grows and this could happen more often;

One of my colleagues suggestions was to make a monolith out of the three other projects.

Question: What subjects would you recommend me to study to solve this questions? Can you point me some articles?

Thanks a lot :)

Upvotes: 1

Views: 476

Answers (1)

jckmlczk
jckmlczk

Reputation: 632

I would point you to your own npm registry for Toolkit library, assuming you're using typescript.

Then follow semantic versioning rules as a team:

  1. MAJOR version when you make incompatible API changes,
  2. MINOR version when you add functionality in a backwards compatible manner
  3. PATCH version when you make backwards compatible bug fixes.

Publishing to your own registry assures everyone on the team follows introduced changes. It is very useful to automate version bumping with CI, so versioning conflicts are not a problem. You can also think about generating a CHANGELOG with conventional commits, so the team is up-to-date.

Then apply a strategy of your choice for introducing major releases (git tags or branches with major releases). This will allow your team to track what version has been installed in every project and provide minor fixes to separate versions.

Finally, many changes introduced to general purpose libraries result in API degradation. A solution for that may be adding extensions to existing Types, or Components etc. or just adding deprecation warnings on legacy code and introducing newer, improved code next to existing one.

It is always at cost of having a bigger code base and possibly repetitions, but with this approach production code can be more stable.

Upvotes: 0

Related Questions