> Would clearly be a better name It appears that it wanted to be services.WeatherService, which if reduced to service.Weather isn't looking so bad, but core e

> Would clearly be a better name It appears that it wanted to be services.WeatherService, which if reduced to service.Weather isn't looking so bad, but core ended up being introduced because the unnecessary interface already overloaded the namespace. The code doesn't accidentally highlight - it is crying out. > always makes me feel like my types are dangling out in space That's the idea, though, isn't it? Each package is its own distinct thing, intended to be useful and usable across many projects. There shouldn't be any kind of deep interconnectedness in most cases – and where there needs to be, you will typically place the related packages in a subfolder to communicate that relationship. I can't think offhand of any package manager that maintains anything other than a flat list of dependencies, and that's essentially what you are building here too. I do think you have a point that many other ecosystems have a mindset where you are only building a single application with no attempt to find reusability beyond the immediate codebase. In large part because those languages/ecosystems require a bunch of extra, often complex, steps to make packages exportable. It can be a bit of mental shift to consider an application as a set of discrete, reusable parts if you come from those places.