Add a peer dependency on fastify to fix TypeScript types

[walkerburgin]

The TypeScript typings in types/index.d.ts import explicitly from fastify without this package taking a dependency on fastify. If consumers are using a strict package manager like PNPM or Yarn (Berry), the typings are currently broken. This PR adds a peer dependency on fastify to fix TypeScript typings.

Checklist

• run npm run test and npm run benchmark
• tests and/or benchmarks are included
• documentation is changed or added
• commit message and code follows the Developer's Certification of Origin
  and the Code of conduct

[jsumners]

Thank you, but peer dependencies cause too many problems. As an org, we avoid them.

[walkerburgin]

Mechanically, anything that ensures that fastify is installed and visible from the install location of @fastify/http-proxy will fix the issue that I'm encountering. I think a peer dependency (or even an optional peer dependency) is the pedantically correct choice, but moving fastify from a devDependency to a dependency would work as well. Would you be open to that instead?

[jsumners]

I don't know what the issue is or how to solve it. That'd be down to the @fastify/typescript folks. I just know that peer dependencies cause more headaches than they solve.

[mcollina]

@walkerburgin can you assemble an reproduction of this problem? Because I'm not seeing it in my codebase: pnpm creates a directory structure that resolves this correctly.

[walkerburgin]

Here's a repro: https://github.com/walkerburgin/fastify-http-proxy-repro. It turns out there's a similar issue with @types/ws as well.

The error repros when you set hoist = false, which configures PNPM to be strict and require that all dependencies be fully declared. That type of strict correctness is valuable in scaling very large monorepos (see here for example). I haven't tried, but I expect that we could repro the issue with Yarn's PnP as well.

[mcollina]

Unfortunately peerDependencies cause more problems that they are worth (especially with such a wild range of versions of npm, yarn, pnpm etc). We tend to follow the "standard behavior" of npm as much as possible.

Setting hoist = false is actually self-inflicted problems.

I'm closing this for now.