Hacker News Reader

Comment by skybrian | Hacker News Reader

It's worth pointing out that when working in a monorepo, there are no version numbers and no package system to tell you that upstream broke you, or you broke something downstream.

So how do you find bugs? You run tests.

The same can be true if you're working with package management. Most bugs aren't found by the dependency tracking system anyway. Having good tests will tell you about incompatibilities that upstream didn't even know about.

If you're not using exactly the same versions that the maintainer used, you need to run tests.

Maybe people currently don't run tests often enough? But this suggests a different approach to software robustness than comparing version numbers.

View on HN

Testing and package management aren't mutually exclusive. If you're in a monorepo, all your code evolves in lockstep. A core tenet of versioned package management is to get reproducible builds that only need to break once you choose to evolve forward in time (i.e. upgrade).

Historically, most languages (C, C++, pre-Maven Java) haven't had package management at all, and so dependencies have typically been managed by vendoring the code (or JAR files). JAR files worked okay, but vendoring incurs maintenance overhead that isn't acceptable in today's environment. git submodules are theoretically a solution, but also high-maintenance.

Yes, you are right. And I believe vgo is supposed to guarantee reproducible builds just like other package systems.

However, when you upgrade a dependency, it's still possible that you're using a particular combination of library versions that have never been tested before.

Some incompatibilities can be prevented by looking at version constraints. But you're not left with no error detection if the package system fails to detect an incompatibility; in the end, what matters is that the code compiles and the tests pass.

This methodology places way too much emphasis on the breadth of the tests into a test centric view— say you had a dep that had an SSL vulnerability - most of the time you’re not going to be checking for this type of thing at the level of your app, and doing so - but you bet you need to ensure that you are using the version of the dep that has the vulnerability fixed

I'm not sure they're entirely distinct. For example, if the SSL library exports a constant containing a version number, you could write a test asserting that it's not the bad version.

It's not as good as testing for the vulnerability, but then again no form of version number checking does that. (This is similar to the principle in web development that feature detection is better than version string checking. But sometimes version-checking is the best you can do.)

Checking version numbers in the package system allows for much faster backtracking, making it feasible to try many versions and select a combination that (hopefully) works. But verification can be done using testing.

Reply on news.ycombinator.com