Q: What would you expect from package managers?

[arcanis]

The @types packages (and particularly whether dependencies should be regular deps or peer deps, big subject) is a bit messy in terms of dependency graph. I was wondering if you had a rough idea what would the absolute best case look like, assuming an ideal world where perfect solutions exist.

For example, would it be peer dependencies everywhere? Regular deps everywhere? A bit of both? Unlisted dependencies? A separate dependency field that package managers would understand (typedDependencies or whatever)? No more @types package and .d.ts into every package? The package manager downloading the types without needing markup?

Even as a thought experiment I think it can be interesting to hear your opinion about "split ecosystems" such as what TypeScript users experience.

[sandersn]

We've debated this in the Typescript team and I think the consensus is that we'd like a new dependency "typeDependency". But that's not perfect and requires lots more work from various people than other solutions.

If you look on this repo and the Typescript repo, I think you'll find more discussion of the problem.

[arcanis]

Something I've been thinking lately was that perhaps packages should, as a general rule, simply list all their dependencies - regardless whether they'd be useful or not - and leave it to the package managers to remove the dependencies that don't make sense given the user context. For example, it would be trivial for us to simply ignore all @types dependencies.

The advantage with such an approach is that it's very backward compatible by design: the worse that can happen is that some users download some extra packages on older systems - which is better than not listing dependencies and introducing undefined behaviors.