Manage library version on multiple repositories

Question

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

Answer 1

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.

Answer 2

undefined method %' for nil:NilClass means you're trying to use % on nil. nil is what you get when you, for example, try to get too much out of an Array.

If we put p "#{i}: #{nums[i]}" in the loop we'll see that i goes to 20. Arrays start counting at 0, so if you have 20 elements in an array the highest index is 19. num[20] is nil.

You can fix this with while i < nums.length to stop at 19.

However, one rarely writes while loops in Ruby. Instead, you iterate using methods. each iterates through each element of an Array. And you can count down with downto.

nums.each do |num|
  check = 0

  num.downto(1) do |divider|
    if num % divider == 0
      check += 1
    end
  end

  #Only division by 1 and itself will increment $check
  if check == 2
    prime_nums.append(num)
  end
end

Now there's no chance of being off-by-one.

Answer 3

The answer from @Schwern has great advice on using iterating methods in Ruby. We can use them to make your algorithm much more efficient.

def is_prime?(num)
  2.upto Math::sqrt(num) do |divisor|
    return false if num % divisor == 0
  end

  true
end

Rather than iterate down from num to 1 and keep track of divisors, we can start from 2 and work up to the square root of num. If we find an even divisor, we know it's not prime and can immediately return false, saving ourselves the effort of iterating over anything further.

If we reach the end of the loop, we know num must be prime and return true.

Then let's say we want to print primes from 1 to 500, we can do:

1.upto 500 do |num|
  puts num if is_prime? num
end