#2396 looks related? likely not

This happens because typescript is a peer dependency of ts-pnp (a subdependency of next).

I am not sure we can solve this.

This happens because typescript is a peer dependency of ts-pnp (a subdependency of next).

I was looking at this too but could not figure out why pnpm and yarn/npm chose to treat it differently (ok, did not read code). What is the "correct" way to navigate this then?

This happens because typescript is a peer dependency of ts-pnp (a subdependency of next).

Looking a bit closer;

• its set as optional via peerDependenciesMeta
• typescript is defined in devDependencies

..shouldn't it be evaluated as a peerDependency only if doing an install that should cover devDependencies?

Maybe prod dependencies should never use dev dependencies to resolve their peer dependencies. But that would break a workflow that currently works.

I'd rather leave it as it is. Peer dependencies are too complex currently. Also, npm wants to make some changes to peer dependencies, it wants to autoinstall them again. So I guess this current behavior of pnpm is kind of like that.

Also, npm wants to make some changes to peer dependencies, it wants to autoinstall them again.

Is there an upstream issue to read up on?

I am personally not happy about it. Peer dependencies are so hard that I'd never touch them again

npm/rfcs#43

I am personally not happy about it. Peer dependencies are so hard that I'd never touch them again

Long read, but I agree with you.

Maybe prod dependencies should never use dev dependencies to resolve their peer dependencies. But that would break a workflow that currently works.

I couldn't find a reference to production dependencies peeking into devDependencies for resolution though. Is there some other rfc other than the linked one?

I'm also getting typescript when installing @nestjs/graphql which has ts-morph as a devDependency and optionalDependency (not peerDependency). ts-morph has a dependency on typescript, but doing a pnpm prune --prod or production install, it should ignore @nestjs/graphql's devDependencies and optionalDependencies. @zkochan thoughts?

So, reading the rrfc about opt out for this scenario there seems to be progress on this matter. As I read @isaacs's comment, shouldn't --no-optional in current npm also apply here?

I stumbled upon this issue after noticing 404 not found errors for internal devDependencies (rush monorepo), these packages are only ever referenced as devDependency, so it should not error out when trying to pnpm install --production
Edit: looks like this related to #881

I am not sure it is worth fixing. There are too many edge cases.

Let's assume there is bar that has foo as a peer dependency. In the following case, bar will resolve its peer depenendency both from a prod foo and a dev foo:

prod
+bar
+qar
  +foo
  +bar

dev
+ foo

It is impossible to solve this problem in a way that will satisfy all use cases.

If you really don't want foo to be linked into bar, I would recommend to remove foo from the peer depenendecies of bar, using a pnpmfile hook

If you really don't want foo to be linked into bar, I would recommend to remove foo from the peer depenendecies of bar, using a pnpmfile hook

For others (hello, google) wanting to do the same - here's the relevant documentation.