[turborepo] Cannot find module 'ui' or its corresponding type declarations.ts(2307)

[idelice]

What version of Turborepo are you using?

latest

What package manager are you using / does the bug impact?

Yarn v1

What operating system are you using?

Windows

Describe the Bug

As the title says, I'm constantly getting this typescript error whenever I modify a simple UI component inside packages/ui - regardless if I'm running the server in dev or building or simply nothing.

Sometimes restarting the dev server and restarting typescript server in vscode fixes the issue.

I have experienced this with multiple turborepo repositories and so has my friends.

It's extremely annoying that I have to restart the dev server and typescript server several times during the development phase - in hope that it fixes the issue.

Expected Behavior

I expected the ts environment to be smart enough to understand that a UI component has changed and not throw any ts error when technically there aren't any.

To Reproduce

Create a turborepo project and modify a UI component or create your own and modify it.

Reproduction Repo

No response

[tknickman]

Thanks for the issue @Delice0, we've seen this one before as well. I haven't been able to nail down a consistent reproduction yet that we could use to fix or take to the Typescript team. When I have seen this, restarting the Typescript Server in VSCode does fix it for me - but if you have more details, let us know!

[keon]

Been experiencing this as well. sometimes works when I open package.json in the dependency library. Its bad for DX

[veksen]

Is this exclusive to yarn v1? Experiencing the exact same cloning the kitchen-sink example (npx create-turbo@latest -e kitchen-sink) with Yarn v1

[theIYD]

I am also experiencing the same.

In the case of having a package and app server running concurrently, when I modify anything inside package, on the package successfully getting built, the app server throws the TS error (mostly imports not found).

To resolve it, I need to restart the app server. It's a major hit on developer productivity when having a design system under packages being used by multiple apps which need to be running together.

[vaynevayne]

same issue, use pnpm@7 or pnpm@8

[vaynevayne]

Thanks for the issue @Delice0, we've seen this one before as well. I haven't been able to nail down a consistent reproduction yet that we could use to fix or take to the Typescript team. When I have seen this, restarting the Typescript Server in VSCode does fix it for me - but if you have more details, let us know!

hi, https://github.com/vercel/turbo/issues/5044 This can be reproduced, just use your own example.

[deltaepsilon]

I'm running into the same issue on the Highlight repo.

Steps to reproduce in PowerShell:

• git clone git@github.com:highlight/highlight.git && cd highlight
• git submodule update --init --recursive
• yarn
• cd .\sdk\highlight-node\
• yarn typegen

[FeMaffezzolli]

Having the same problem. Running "Typescript: Restart TS Server" fixes the problem .. but I have to run it a dozen times per day.

[lamualfa]

Having the same problem. Running "Typescript: Restart TS Server" fixes the problem .. but I have to run it a dozen times per day.

Same with me :) The package type won't refresh after changing the source. I need to restart the TS Server to refresh it.

[miroslavlalovic]

Yup, happens on my project as well, was unable to figure out why. Is there any update regarding this issue?

[tknickman]

Was discussing this with @lfades, and he recommended using typesVersions to work around this issue:

For example:

  "typesVersions": {
    "*": {
      "*": [
        "src/*",
        "src/*/index"
      ]
    }
  },
  "publishConfig": {
    "typesVersions": {
      "*": {
        "*": [
          "dist/*.d.ts",
          "dist/*/index.d.ts"
        ]
      }
    }
  }

This ensures that:

1. During dev, your TS types point to the source files, and don't have a reliance on the build process, or dist existing.
2. For production, the built dist outputs are still used.

This works well for multiple entry points as well, for example:

  "exports": {
    "./*": "./dist/index.*.js"
  },
  "publishConfig": {
    "typesVersions": {
      "*": {
        "*": [
          "./dist/index.*.d.ts"
        ]
      }
    }
  },
  "typesVersions": {
    "*": {
      "client": [
        "./src/client/index.client.tsx"
      ],
      "server": [
        "./src/server/index.server.ts"
      ]
    }
  },

From my own experimenting, this looks to have resolved this issue for me! We'll look into getting this ported into our examples.

[rafaelsmgomes]

Thanks @tknickman ! This worked for me!

[zigang93]

can this update on example?

[hdck007]

@tknickman can you please explain that a bit if possible or atleast point out some resources from where i can refer it

[JoseGarciaM]

Still get the error even with the proposed fix. Clonning the tailwind example, just changed the package.json with the recommended fix but... nothing. Restarted TS server, etc and nope

[vaudy]

Same thing here, this fix don't work turbo is able to track the dependency list correctly but wont build them in order to have the dist generated once ready to build the next dependency

libA > libB libC > libB libB > libD

libD should be built first in order to build libB then libA/libC in parallel

[me-imfhd]

done almost all but nothing worked, can this issue be re open and fixed ?

[3mil0]

The thing is the proposed fix, isn't a fix. It's a hack / work around to point to local files instead of the built ones for types. It has the potential to lead to inconsistent results due to not using the built assets.

Partially, I think this issue is an artifact of mixing esm/cjs projects that require being built within the same ecosystem. As the industry leans more towards pure esm this will be less of an issue.

Right now though, unless the typescript server also listens to changes and updates itself accordingly I don't think there is a solution that is just gonna work out of the box.

As for a solution, it's probably better that someone with extensive knowledge of the relevant topics documents this as a sorta "gotcha" issue and provides people with the actual issues and potential work arounds.

[theIYD]

The proposed solution still not works on HMR. Whenever a line is changed in packages, the package rebuilds, but the app throws the same error of not finding the type declarations.

[owieth]

I encountered this problem when I integrated an old repository into my new turbo repo.

Config of my tsconfig package (packages/tsconfig):

{
  "$schema": "https://json.schemastore.org/tsconfig",
  "display": "Default",
  "compilerOptions": {
    ...
    "moduleResolution": "node",
    ...
  },
  "exclude": ["node_modules"]
}

When you create a standalone NextJS project, the tsconfig will look like this:

{
  "compilerOptions": {
    ...
    "moduleResolution": "bundler",
    ...
  },
  "include": ["next-env.d.ts", "**/*.ts", "**/*.tsx", ".next/types/**/*.ts"],
  "exclude": ["node_modules"]
}

When creating the Turbo Repo, the NextJS project will have the tsconfig compilerOptions with "moduleResolution": "node" but a standalone NextJS project has "moduleResolution": "bundler", which causes the error.

To fix:

"moduleResolution": "bundler", -> "moduleResolution": "node",

[zhm]

I was having this exact same problem with the with-tailwind example where VSCode would not be able find the ui module after a rebuild of the ui package. After some digging I discovered that the dist/index.d.ts was briefly disappearing when the ui package rebuilt. I think this problem is caused by tsup deleting dist/index.d.ts and then re-creating it. The TS server doesn't seem to be able to handle this. When I set clean: false in ./packages/ui/tsup.config.ts it now seems to work fine.

[SeanBarker182]

For those using vite instead of tsup this is the equivalent of @zhm's solution

import { defineConfig } from 'vite'

export default defineConfig({
  build: {
    emptyOutDir: false,
  },
  ⋮
})

You can also pass --emptyOutDir via the cli. Here's an example of my dev command:

"dev": "tsc && vite build --emptyOutDir false --watch"

Feel free to yell at me if you think I shouldn't be using Vite as my bundler for my package. I don't know what I'm doing.

[me-imfhd]

btw i faced this issue for a very long time, for me it turned out to be 1) my pc had issues, i swtiched to ubuntu (just delete everything and do everything from start) 2) be very careful with package.json, the dependencies it has is the key to your packages if using pnpm use pnpm workspaces then you have to add "workspace:" for local package dependencies version if using yarn or npm watch for root dir package.json and just use for local package dependencies version, https://github.com/me-imfhd/turbocell take reference

[Psycarlo]

Not sure what is happening on my case.

It works with yarn dev but does not build with yarn build

I get Cannot find module 'ui' or its corresponding type declarations.

In my ui package.json:

  ...
  main": "./dist/index.js",
  "module": "./dist/index.mjs",
  "types": "./dist/index.d.ts",
  "exports": {
    ".": "./dist",
    "./styles.css": "./dist/index.css"
  },
  "files": [
    "dist/**"
  ],
  ...

If I do @ts-ignore the line, it builds and the preview is okay.

[bibek-magar]

I was having this exact same problem with the with-tailwind example where VSCode would not be able find the ui module after a rebuild of the ui package. After some digging I discovered that the dist/index.d.ts was briefly disappearing when the ui package rebuilt. I think this problem is caused by tsup deleting dist/index.d.ts and then re-creating it. The TS server doesn't seem to be able to handle this. When I set clean: false in ./packages/ui/tsup.config.ts it now seems to work fine.

I set clean to false and tried restart the server but still same issue persist any alternative?

While building also it says Type error: Cannot find module 'ui' or its corresponding type declarations.

[Psycarlo]

I found the problem. I had the following in my ui shared package:

...
"exports": {
  ".": "./dist",
  "./styles.css": "./dist/index.css"
},
...

Once I removed it, I could now run yarn build successfully.

However yarn dev now fails: Failed to resolve entry for package "ui". The package may have incorrect main/module/exports specified in its package.json. [plugin vite:dep-scan]

If we add the following lines to our vite.config.ts: optimizeDeps: { exclude: ['ui'] }

Now, yarn dev also runs.

References: OptimizeDeps Exclude Pre Bundling

The problem is that you need the exports in order to be able to import the styles in each app:

import 'ui/styles.css'

So, your exports in package.json will look something like:

...
"exports": {
  ".": {
    "types": "./dist/index.d.ts",
    "default": "./dist",
    "node": "./dist",
    "import": "./dist"
   },
  "./styles.css": "./dist/index.css"
},
...

[xtiannyeto]

In my project I have 2 packages,

• typescript lib for the server(Nestjs)
• ui generated by turborepo for the front (NextJs).

Both build are ok, and in vscode I have the right references. however : yarn dev server ----> failed Cannot find module lib xxxxx yarn dev front ------> OK

I have looked into the front project closely and . I have seen in the next.config.js

module.exports = {
  reactStrictMode: true,
  transpilePackages: ["ui"],
};

Apparently the attributes transpilePackages allow you to bundle a dependency from local. read more here

[Rudra-Sankha-Sinhamahapatra]

i have also exported it correctly but dont know why its showing the error can someone suggest me something

[priyanshu07222]

today, I was also facing the same issue,

try this

1. go to the root folder
2. run -> npm i

it worked for me, Hope will work u too.

[Rudra-Sankha-Sinhamahapatra]

naah that was not the issue . The issue was was not exporting as .ts i included .ts at the end then it got resolved

[gajendar-work]

today, I was also facing the same issue,

try this

1. go to the root folder
2. run -> npm i

it worked for me, Hope will work u too.

for some weird reason , i tried it and it worked , whattt....

[unitof]

Adding that, in my case, for a just-in-time internal package shared across multiple apps in a Turborepo, I had to do the opposite of @owieth above.

I had to change from "moduleResolution": "node" to "moduleResolution": "NodeNext" (or bundler).

I have a very simplepackages/sanity-client which just exports an object shared across many of my apps, but after months of building fine began getting Module not found: Can't resolve '@repo/sanity-client' build errors.

Once I added an exports to my packages/sanity-client/package.json, I got a more helpful error:

bh-briet-market:build: Type error: Cannot find module '@repo/sanity-client' or its corresponding type declarations.
bh-briet-market:build:   There are types at '/vercel/path0/node_modules/@repo/sanity-client/main.ts', but this result could not be resolved under your current 'moduleResolution' setting. Consider updating to 'node16', 'nodenext', or 'bundler'.

My two apps had been set up with a default of "moduleResolution": "node",, but changing to "moduleResolution": "nodenext", (or bundler, depending on your taste for file extensions) was the key, along with adding

"exports": {
  "default": "./main.ts"
},

to my packages/sanity-client/package.json.