Code that imports a dependency from one of it's dependencies does compile (even if it doesn't explicitly add it to it's dependencies), it surprises me as it would imply, for a package, that changing a dependency (even just the major version) is a source breaking change as clients might also depend on it?
If you consciously import it, declare it as your own dependency too.
Some amount of implicit re‐exporting is usually necessary. That whole problem domain is a bit of a mess right now though:
This is not Swift‐specific. Even if all you do is reduce the range of a dependency you declare compatibility with, you’ve reduced the range of that same dependency that your clients can use at the same time as your package. The general principle of semantic versioning is that your version only represents your own vended API. If your client discovers they care about the differences in a sub‐dependency, they can declare it as their own dependency and select whatever range they want. It may restrict them from updating yours, but nothing breaks in their code. If they don’t notice, and their client doesn’t notice, and their client’s client doesn’t notice, then their client’s client’s client still has the same recourse to declare it themselves, so nothing is ever broken.
Thank you for this information, it didn't feel like a correct approach to do this but I was surprised that it was actually allowed by the compiler without any warning, it's nice to know that it will probably improve in the future.