Hacker News Reader

Correct way is to have everything as-if a source dependency, but a globally shared cache system that can automatically provide artifacts if that exact version of source has already been compiled.

Any system that can only consume manually built (and even in worst case, only tagged and globally pushed) dependencies is horrible for cross-module development, like large scale refactorings and the like.

View on HN

This is exactly what I disagree with. It forces you to consider git your package boundary. You're now organising your source as if it was a package registry, when git can (and should) be orthogonal to that. Your problem with cross module development may even be because you're using git this way. If you want to do cross package development, having them in a monorepo and building two artifacts is the easy way. If that's not an option because the two packages need to be separate, you need a workflow that pulls the source together again.

To say nothing about hardcoded repo URLs (not resolvable identifiers), transient dependencies, URL schemes, and trying to pretend github is the only package source.

Reply on news.ycombinator.com