pnpm, hoisting and TypeScript monorepos

[jgoux]

Hello all 👋,

I'm trying to setup a monorepo based on pnpm, TypeScript and I have issues with hoisting.

The best practice is to not hoist so I want to avoid node-linker so my packages are all nicely isolated. However, I'm hitting this TypeScript error as soon as I share types between my packages:

• The inferred type of "X" cannot be named without a reference to "Y". This is likely not portable. A type annotation is necessary. microsoft/TypeScript#42873
• "The inferred type of X cannot be named without a reference to Y" (TS2742) occurs when multiple modules with the same package ID are resolved microsoft/TypeScript#47663
• The inferred type of '...' cannot be named without a reference to '../../lib-b/node_modules/...'. This is likely not portable. #6089

This is quite a recurring issue for pnpm and TypeScript users.

I can partially solve it by adding the external packages in error to public-hoist-pattern[], however I need to manually delete the symlink in the local packages (for example my-project/packages/foo/node_modules/@trpc/server is still created even if @trpc/server was added to public-hoist-pattern[] and is now present in my-project/node_modules/@trpc/server). Is that normal? Can it be avoided with pnpm options?

This is only half of the issue. The other part is about internal packages which share types. In this case, we can't use public-hoist-pattern[] on them, so I find no "proper" way of solving this for this use case. Could we have public-hoist-pattern[] working with internal packages? I think right now the only solution would be to install them in the root, but that's just wrong. 😅

It seems a legitimate use case for supporting this: #3642

[1oglop1]

Hi, I am battling with monorepo and TS as well.
I wonder if this solves the problem for you.

  "devDependencies": {
    "@myInternalPackage": "workspace:*"
  }

[jgoux]

Hi, I am battling with monorepo and TS as well. I wonder if this solves the problem for you.

  "devDependencies": {
    "@myInternalPackage": "workspace:*"
  }

Hey @1oglop1, I'm already declaring my dependent packages, yes, and it doesn't solve the issue, unfortunately.

[weyert]

If I understand the problem correctly. I sometimes fix this issue by making sure to also manually import the type in the file to help TypeScript a hand

[iobuhov]

I had something similar. But it was because of peer dependency of one of my lib was declared as "@types/plotly.js": * and I assume it forced pnpm to resolve wrong dependency. As the result I had two libraries that should depend on different versions, but instead shared most latest version of types. So, obviously tsc (which has it's own resolution straregy) was really unhappy about it.
The solution was to prune store, remove node_modules, remove lock file and install all "fresh" with aim to repeat package resolution step. It helped, so, this approach bit brutal, but it may work.

[jgoux]

My current solution is to hoist the Y library from this error The inferred type of "X" cannot be named without a reference to "Y". to the root of the monorepo, so it doesn't involve:

• writing custom code, like the import type {} from 'Y' which also requires the consuming library to add Y as its dev dependencies
• relying on tsconfig's paths. I think paths should only target things internals to the package (for example aliasing src to ~)

The steps needed to make it works:

• Add the Y library to .npmrc: public-hoist-pattern[]=*@types/debug*
• In the consumer package, the package will still be installed under consumer/node_modules so you need to delete the symlink so the resolution will pick the Y library installed in the root of the monorepo. I do it in a postinstall script in the consumer package:
  "postinstall": "rm node_modules/@types/debug"

After these steps, everything is working.

[dmichon-msft]

Typically, this class of error: The inferred type of "X" cannot be named without a reference to "Y" is best avoided by providing explicit type annotations for all exports (which also helps make your code much more readable and easier to review in isolation). Hence the A type annotation is necessary part of the message.