Unify development dependencies

[deivid-rodriguez]

Just curious to see what breaks if we unify our development dependencies.

[jeffwidman]

Looks like nothing breaks. 😀

[deivid-rodriguez]

The downside of this PR is that some dependencies are no longer locked in CI now. That means CI is less deterministic and potentially could get affected by issues in dependencies. For example, I guess there was a reason why vcr was pinned to 6.1.0. Now it's more unlocked.

But this may be acceptable.

[deivid-rodriguez]

After a second look, the only dependency that got relaxed with these changes is vcr. I'm happy to change this to keep that pin.

[deivid-rodriguez]

I was not too happy about the previous approach, because it was adding dependencies to the updater that it didn't really need. I changed the approach so that the set of dependencies used by /updater is exactly the same.

It's probably a bit too hacky, but essentially the same thing other gemspecs are doing by pulling development dependencies from common.

Let me know what you think!

[jeffwidman]

This way of doing it makes sense to me, totally fine with the hack, since these two libs/apps are effectively joined at the hip into a monorepo.

[Nishnha]

I think this is an okay approach. I agree with @jeffwidman that this is effectively a monorepo of core and updater anyway, so it makes sense to share dev dependencies.

I had one minor nit but it's not blocking

[deivid-rodriguez]

It worked! 🥳