undefined | Better HN

0 pointseropple7y ago0 comments

So, two things:

I'm sorry that you've gotten bitten because it's frustrating when it happens, but "if a package requires a peer dependency,it's probably not worth using" is some cargo-cult stuff. Anything that acts as a extension system (coded to an interface) should use the project it's extending as a peerDependency. They are not "global variables", they're interfaces. It's what you're writing against! If you end up in dependency hell because of them, that means your dependencies are not speaking to the same interface, and that means you need to resolve the problem. Which can suck, I guess, having to actually do some work as a programmer, but somehow I think we'll all muddle through. Because the alternative is to silently have different APIs that will later break because the extended system has changed, and that is rather worse than actually knowing what's going on in your system.

React is a system that exists to be extended. Peer dependencies exist to facilitate this. Understanding one's tools makes cargo-cult sweeping-statement fears about milquetoast stuff really just unnecessary.

Flatpak is whatever (it's fancy /opt, that's fine) but, "jumping outside the web world", I'll put on my platform-architecture-is-my-actual-real-job hat right now and point out that Docker, while certainly appropriate for some use cases, is, for example, happy to cost you money in production when your big ol' app (shouts to my 4GB-heap-before-taking-a-request Ruby clients) can't copy-on-write. (After all, each process is supposed to be isolated, right? I mean, that's what people think...) There are real drawbacks to this approach, it's orthogonal to actually writing code, and the analogy doesn't really hold besides.

0 comments

danShumway7y ago

There is not a huge fundamental difference between a global variable and a global interface. That doesn't mean that interfaces are bad, but it means you should minimize the number of globally accessible interfaces that you have, and where possible opt for local interfaces that are accessible only to the classes that are extending them.

In any case, peer dependencies are a heck of a lot more than just an interface. They're a shared implementation. That's way more dangerous.

You're looking at this from the perspective of "well, my peer dependency is the interface I've blessed." What I'm saying is that for any long-lived project you are inevitably going to get parts of your implementation, interface, and toolchain wrong. It is therefore in your best interest to optimize for small, encapsulated interfaces that will be easy to remove or change later.

Unless you're working on a trivial project, you likely do not know enough about your project to bless an interface. You almost definitely don't know enough about your project to guess in advance which interface future 3rd-party dependencies will be using. You absolutely don't know enough about your project to guess whether or not your dependencies can rely on an evergreen codebase rather than a static one that you test once and then leave unchanged for the entire component lifecycle.

It's OK if you think I'm wrong about that. I probably would not have agreed with this two years ago. And you could very well be right and in two years my opinion might flip again. All of this is just opinion me, I've gone out of my way to say that none of what I'm talking about is a universal rule - you are going to need to share at least some environment code with your dependencies.

But it's usually true. You don't need to join a cargo cart to understand that some ideas tend to be better than others on average. It's not that I don't understand my tools, it's that I understand that tools evolve.