Issues with TypeScript types not being hoisted

[ericmatthys]

It is relatively common for a dependency's types to import their own dependency's types. In a repo with pnpm that is not hoisting packages, this leads to issues with TypeScript being unable to find these types, resulting in any types and sometimes errors. It seems like the main way people are fixing this issue is with public-hoist-pattern. However, the list just keeps growing as I bump into issues. A pattern like @types/* covers some of them, but there are plenty of other common packages with issues, like:

• @types/react imports types from csstype
• @sentry/browser imports types from @sentry/types and @sentry/core
• msw imports types from @mswjs/interceptors and others
• and so on...

The less that @types is used (which is a good thing overall for the ecosystem and the direction we are going) the worse this problem gets. Adding all of these inner dependencies as direct dependencies also seems like a headache (what do you do with versions / upgrades?). These are not peer dependencies so there's no visibility of issues unless there are compile errors or you bump into an unexpected wall looking through types.

How are others approaching this issue? While I appreciate the overall philosophy of not hoisting packages, this issue is a consistent sticking point.

[ericmatthys]

@zkochan Any thoughts on this? It's still a pain point for me and it seems like it must be a common issue unless I'm holding something wrong.

[iobuhov]

I think pnpm behavior is correct, as it use isolation. I run into same problem in our monorepo, but I solved it by adding types explicitly as direct dependency, and I think this is right approach. But I never run into issue with transitive dependencies. Which I think might be a problem if you set types filed in your tsconfig.

Also, we setup renovate bot to bump our deps, and he does a great job batching @types updates for all packages. If you don't use renovate, you can use snycpack, but I never used this tool, just saw it on pnpm website.

[SukkaW]

I am also running into this issue. @swc/core has its types from @swc/types

[SukkaW]

There is also @typescript-eslint/utils and its dependency @typescript-eslint/estree. It is a widespread issue now.

[shellscape]

@zkochan I just ran into this today with both 9.15.9 and 10.8.1. specifically, tsc fails to see types correctly from @types/react to imports from csstype. When I asserted shamefullyHoist (or --shamefully-hoist on 9.x) those resolution issues went away. It's a transitive dependency resolution issue.

I also ran into this with vite and types that it imports. Here's a reproduction repo: https://github.com/shellscape/pnpm-hoist-tsc-bug. If you run the install as-is and then run pnpm --filter jsx-email build you'll see no errors. To repro:

• Remove the shamefullyHoist setting from the pnpm-workspace.yml file
• rm -rf node_modules
• pnpm i
• pnpm --filter jsx-email build and you'll see fresh type errors

Secondarily, toggling shamefullyHoist to false after an install has been run with it true does not prompt the user to rebuild node_modules. It's only going from false to true which does. That seems like a secondary bug.

[shellscape]

tracking this issue here: #9428

[anthonyalayo]

I'm hitting the same issue. My build doesn't succeed even if I use both --shamefully-hoist and --node-linker=hoisted. I'm surprised no one else is talking about this.

[zkochan]

These types should be in dependencies. Probably peer dependencies. This .pnpmfile.cjs solved the issue with typescript in a workspace that uses react:

module.exports = {
  hooks: {
    readPackage (pkg) {
      if (pkg.dependencies['react'] || pkg.peerDependencies['react']) {
        pkg.peerDependencies['@types/react'] = '*'
      }
      return pkg
    }
  }
}

[SukkaW]

Reproduction:

git clone https://github.com/SukkaW/eslint-config-sukka && cd eslint-config-sukka
pnpm i
npx tsc --noEmit

Though @typescript-eslint/scope-manager is a direct deps of @typescript-eslint/utils, pnpm doesn't install @typescript-eslint/scope-manager.