build fails when using yarn 4 with pnp and rollupTypes: true

[auirarrazaval]

Describe the bug

Hello!

I have recently updated a Vue library source code to use yarn 4.3.0, which uses PnP logic instead of the classic node_modules approach. Serving works just fine, as well as a separate Storybook build and deployment I have running (which doesn't use dts).

The error i get is that when vite starts rolling up the declaration files, i get the following error:

[vite:dts] Start generate declaration files...
computing gzip size (134)...[vite:dts] Start rollup declaration files...
Analysis will use the bundled TypeScript version 5.3.3
x Build failed in 11.03s
error during build:
Error: [vite:dts] ENOTDIR: not a directory, lstat '/node_modules/@vue/runtime-core/dist/runtime-core.d.ts/package.json'
    at makeError$1 (/home/alfonso/Tether/frontend/design-system-vue/.pnp.cjs:16318:24)
    at ENOTDIR (/home/alfonso/Tether/frontend/design-system-vue/.pnp.cjs:16336:10)
    at ZipFS.resolveFilename (/home/alfonso/Tether/frontend/design-system-vue/.pnp.cjs:20986:15)
    at ZipFS.realpathSync (/home/alfonso/Tether/frontend/design-system-vue/.pnp.cjs:20777:28)
    at /home/alfonso/Tether/frontend/design-system-vue/.pnp.cjs:18298:102
    at /home/alfonso/Tether/frontend/design-system-vue/.pnp.cjs:18812:66
    at ZipOpenFS.getMountSync (/home/alfonso/Tether/frontend/design-system-vue/.pnp.cjs:18919:14)
    at ZipOpenFS.makeCallSync (/home/alfonso/Tether/frontend/design-system-vue/.pnp.cjs:18812:17)
    at ZipOpenFS.realpathSync (/home/alfonso/Tether/frontend/design-system-vue/.pnp.cjs:18290:17)
    at VirtualFS.realpathSync (/home/alfonso/Tether/frontend/design-system-vue/.pnp.cjs:18990:26)

What seems extremely weird is that it's trying to get a file with the structure node_modules/<library>/dist/<types file .d.ts>/package.json

Upon further inspection, I logged the process used to resolve all paths, and got the following:

# ... (previous logs)
🚀 [TDS] ~ ZipFS ~ realpathSync ~ resolvedP: /node_modules/vite/client.d.ts
🚀 [TDS] ~ ZipFS ~ realpathSync ~ p        : /node_modules/vue/dist/vue.d.mts
🚀 [TDS] ~ ZipFS ~ realpathSync ~ resolvedP: /node_modules/vue/dist/vue.d.mts
🚀 [TDS] ~ ZipFS ~ realpathSync ~ p        : /node_modules/vite/client.d.ts
🚀 [TDS] ~ ZipFS ~ realpathSync ~ resolvedP: /node_modules/vite/client.d.ts
# HEre im guessing starts the rollup
Analysis will use the bundled TypeScript version 5.3.3
🚀 [TDS] ~ ZipFS ~ realpathSync ~ p        : /node_modules/typescript
🚀 [TDS] ~ ZipFS ~ realpathSync ~ resolvedP: /node_modules/typescript
🚀 [TDS] ~ ZipFS ~ realpathSync ~ p        : /node_modules/typescript/lib
🚀 [TDS] ~ ZipFS ~ realpathSync ~ resolvedP: /node_modules/typescript/lib
🚀 [TDS] ~ ZipFS ~ realpathSync ~ p        : /node_modules/typescript
🚀 [TDS] ~ ZipFS ~ realpathSync ~ resolvedP: /node_modules/typescript
🚀 [TDS] ~ ZipFS ~ realpathSync ~ p        : /node_modules/typescript/lib/typescript.js
🚀 [TDS] ~ ZipFS ~ realpathSync ~ resolvedP: /node_modules/typescript/lib/typescript.js
🚀 [TDS] ~ ZipFS ~ realpathSync ~ p        : /node_modules/typescript/lib/typescript.js/package.json
🚀 [TDS] ~ ZipFS ~ realpathSync ~ p        : /node_modules/@vue/runtime-core/dist/runtime-core.d.ts/package.json
x Build failed in 9.83s
error during build:
Error: [vite:dts] ENOTDIR: not a directory, lstat '/node_modules/@vue/runtime-core/dist/runtime-core.d.ts/package.json'
    at makeError$1 (/home/alfonso/Tether/frontend/design-system-vue/.pnp.cjs:16317:24)
    at ENOTDIR (/home/alfonso/Tether/frontend/design-system-vue/.pnp.cjs:16335:10)
    at ZipFS.resolveFilename (/home/alfonso/Tether/frontend/design-system-vue/.pnp.cjs:20954:15)
    at ZipFS.realpathSync (/home/alfonso/Tether/frontend/design-system-vue/.pnp.cjs:20743:28)
    at /home/alfonso/Tether/frontend/design-system-vue/.pnp.cjs:18279:102
    at /home/alfonso/Tether/frontend/design-system-vue/.pnp.cjs:18779:66
    at ZipOpenFS.getMountSync (/home/alfonso/Tether/frontend/design-system-vue/.pnp.cjs:18886:14)
    at ZipOpenFS.makeCallSync (/home/alfonso/Tether/frontend/design-system-vue/.pnp.cjs:18779:17)
    at ZipOpenFS.realpathSync (/home/alfonso/Tether/frontend/design-system-vue/.pnp.cjs:18271:17)
    at VirtualFS.realpathSync (/home/alfonso/Tether/frontend/design-system-vue/.pnp.cjs:18957:26)

Reproduction

https://github.com/auirarrazaval/rollup-rep

Steps to reproduce

Clone the repo, ensure you have yarn 4:

corepack enable
yarn

And build
yarn build

System Info

System:
    OS: Linux 5.15 Ubuntu 22.04.4 LTS 22.04.4 LTS (Jammy Jellyfish)
    CPU: (16) x64 AMD Ryzen 9 5900HS with Radeon Graphics
    Memory: 4.24 GB / 7.76 GB
    Container: Yes
    Shell: 5.8.1 - /usr/bin/zsh
  Binaries:
    Node: 21.6.2 - ~/.nvm/versions/node/v21.6.2/bin/node
    Yarn: 4.3.0 - ~/.nvm/versions/node/v21.6.2/bin/yarn
    npm: 10.2.4 - ~/.nvm/versions/node/v21.6.2/bin/npm

Validations

• Read the FAQ.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• The provided reproduction is a minimal reproducible example of the bug.

[arnoudius]

Can confirm, I'm experiencing the exact same issue.

[lukasschwarz]

Found a workaround:

in the tsconfig.json:
{ "compilerOptions": { ... "paths": { "vue": ["./node_modules/vue"] } ... }

worked for me

[agarwalvaibhav0211]

Can Confirm. Facing the same issue. Any updates on this?

[kris7t]

For me, adding the package path to "path" generated bogus imports in the generated .d.ts file, e.g., instead of

import { default as default_2 } from 'vue';

I had

import { default as default_2 } from '../../node_modules/vue';

However, this seems easy enough to fix with

dts({
  // ...
  async afterRollup() {
    const content = await readFile(path.join(outDir, 'index.d.ts'), 'utf8');
    await writeFile(
      path.join(outDir, 'index.d.ts'),
      content.replace(/\.\.\/\.\.\/node_modules\//g, ''),
    );
  },
}),

We can't do this in beforeWriteFile, because it would override the files before @microsoft/api-extractor processes them. Adjust the output path as needed.

Nevertheless, it would be nicer if vite-plugin-dts could work with Yarn PnP out of the box. Sadly, it seems the the PnP support is currently missing from @microsoft/api-extractor.

[arnoudius]

I managed to get it to work with yarn pnp by using a patched version of @microsoft/api-extractor instead (i.e. via yarn patch). See microsoft/rushstack#4156 (comment) for more details. Would of course be nicer if no patch would be needed, but at least it works now.