1

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 :)

ch0m4
  • 11
  • 3
  • if changing the type causes breaking changing in one project, and you cant update the project to use that type, you should instead extend the types (creating new ones by adding properties). Also, where ever you are storing this package should be able to hold multiple versions, so updating the package version in one project does not require updating the package version in another (while you iron out the issues) – about14sheep Dec 28 '21 at 18:28
  • thanks for your answer @about14sheep ; can you point me directions on what can I study to understand it in more depth? – ch0m4 Dec 29 '21 at 15:12
  • Please clarify your specific problem or provide additional details to highlight exactly what you need. As it's currently written, it's hard to tell exactly what you're asking. – Community Jan 05 '22 at 14:45

1 Answers1

0

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.

jckmlczk
  • 359
  • 4
  • 11