pino-http
pino-http copied to clipboard
pinojs
pino should be a peer dependency
I think pino should be a peer dependency (and also a dev dependency) of pino-http. I'm trying to use a pre-release version of pino, but since pino-http has a direct dependency on pino, the latest release version is also being installed and hides the version I want to use (unless I exclude it from my package-lock.json).
peerdependencies do not work well across all package managers. Specifically npm v6 has a significantly different behavior than npm v8 and yarn.
That's a little vague. Are there specific problems or scenarios you're worried about? Peer dependencies were created in npm 1 for this exact scenario. The behavior did change a bit in npm 7+ (to automatically install peer dependencies if the consumer didn't), but that seems like a good thing. I'm having (temporary) difficulty using this package due to the direct dependency.
FWIW, peer dependencies are also widely used in the react ecosystem across many npm and yarn versions. I've never run into any issues there.
They cause tremendous issues when not installing as a hoisted flat node_modules tree. Even then, they cause difficult problems.
I'd love to learn from your experiences here. Can you be more specific? Googling for things like "peerDependencies problems" isn't yielding much.
Let's say you have a package foo that depends upon bar which itself has a peer dependency of baz. So you write foo such that it has direct dependencies on bar and baz. All is good, you ship.
Now you write an application that uses foo, but also uses baz in its test suite. Depending on how bar looks for baz, it's very likely that bar will not be able to find baz because it has been hoisted away from the right tree.
This is one real example.
I'm having similar issues with pino not being a peer dependency. Using yarn pnp it just errors.
Error: nestjs-pino tried to access pino, but it isn't declared in its dependencies; this makes the require call ambiguous and unsound.
