Wrong typings generated when importing types from a package in a Rush monorepo (PNPM hard links)

Current Behavior

I run tsdx build --transpileOnly

From this source

import { useToast as useChakraToast } from '@chakra-ui/react'
import { useMemo } from 'react'
import type { UseToastOptions } from '@chakra-ui/react'

export const useToast = (options?: UseToastOptions) => {
  const defaultOptions = useMemo(() => {
    return {
      position: 'top-right' as UseToastOptions['position'],
      status: 'success' as UseToastOptions['status'],
      isClosable: true,
      ...(options ?? {}),
    }
  }, [options])
  return useChakraToast(defaultOptions)
}

It generates this d.ts:

export declare const useToast: (options?: any) => any;

Expected behavior

Should output (and this is what regular tsc with emitDeclarationsOnly does):

import type { UseToastOptions } from '@chakra-ui/react';
export declare const useToast: (options?: UseToastOptions | undefined) => {
    (options?: UseToastOptions | undefined): string | number | undefined;
    close: (id: string | number) => void;
    closeAll: (options?: import("@chakra-ui/react").CloseAllToastsOptions | undefined) => void;
    update(id: string | number, options: Pick<UseToastOptions, "status" | "render" | "position" | "duration" | "onCloseComplete" | "title" | "description" | "isClosable" | "variant">): void;
    isActive: (id: string | number) => boolean | undefined;
};

Additional context

It’s Rush.js managed monorepo so it uses PNPM so hard links to link modules into node_modules. I’m using TS 4. A similar workaround mentioned here https://github.com/formium/tsdx/issues/926 (using PNPM fashioned resolutions) is applied.

If built without --transpileOnly fails with

app-frontend/libraries/hooks/common/src/useToast.ts(1,10): semantic error TS2305: Module '"../node_modules/@chakra-ui/react/dist/types"' has no exported member 'useToast'.

Your environment

  System:
    OS: Linux 5.3 Ubuntu 20.04.1 LTS (Focal Fossa)
    CPU: (16) x64 AMD Ryzen 7 3700X 8-Core Processor
    Memory: 449.17 MB / 31.37 GB
    Container: Yes
    Shell: 5.8 - /usr/bin/zsh
  Binaries:
    Node: 14.15.4 - ~/.nvm/versions/node/v14.15.4/bin/node
    Yarn: 1.22.10 - ~/.nvm/versions/node/v14.15.4/bin/yarn
    npm: 6.14.10 - ~/.nvm/versions/node/v14.15.4/bin/npm
  Browsers:
    Chrome: 87.0.4280.88
    Firefox: 85.0

[agilgur5]

For reference, I am fairly sure I fixed this upstream in https://github.com/ezolenko/rollup-plugin-typescript2/pull/332, which fixed https://github.com/ezolenko/rollup-plugin-typescript2/issues/330, which is a very similar upstream issue with pnpm symlinks.

To use that in your project, you can set your pnpm overrides to use rollup-plugin-typescript2 0.32.0+:

{
  "pnpm": {
    "overrides": {
      "rollup-plugin-typescript2": "^0.32.0"
    }
  }
}

And indeed, while the issue is different here, the root cause is the same as #953 so they are effectively duplicates.

@agilgur5 what would you swap it out for? Esbuild? Some other thing?

No, I meant a different Rollup TypeScript plugin. They all have their own issues however and I was already contributing to rpt2 a bit in the past to fix issues from TSDX. I found rpt2 to be the simplest to contribute to by a wide margin, so I actually recently stepped up to help maintain it and have fixed a ton of issues in the past month, including the most long-standing ones like this one with pnpm symlinks. Can see https://github.com/ezolenko/rollup-plugin-typescript2/issues/234#issuecomment-1139202740 for more details on that (and a root cause analysis on this and why TypeScript integrations are difficult to implement due to TS having a sparsely documented API).

[RIP21]

@agilgur5 thank you for your work! I’m no longer working on this codebase to try, but still. Tsdx is my tool to go, so I’m happy it’s probably fixed now.