unjs / unplugin

Unified plugin system for Vite, Rollup, Webpack, esbuild, Rolldown, and more

Home Page:https://unplugin.unjs.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Forces a project to include vite/rollup/esbuild dependencies

rchl opened this issue · comments

Environment

Node 18, Nuxt 2

Reproduction

Create a Nuxt 2 project that uses @nuxtjs/sentry and @sentry/webpack-plugin and try to type check the project using tsc.

Will get errors like:

node_modules/unplugin/dist/index.d.ts(1,40): error TS2305: Module '"rollup"' has no exported member 'AcornNode'.
node_modules/unplugin/dist/index.d.ts(5,36): error TS2307: Cannot find module 'vite' or its corresponding type declarations.
node_modules/unplugin/dist/index.d.ts(6,38): error TS2307: Cannot find module 'vite' or its corresponding type declarations.
node_modules/unplugin/dist/index.d.ts(7,49): error TS2307: Cannot find module 'esbuild' or its corresponding type declarations.
node_modules/unplugin/dist/index.d.ts(8,41): error TS2307: Cannot find module 'esbuild' or its corresponding type declarations.

Describe the bug

I'm using @nuxtjs/sentry with @sentry/webpack-plugin for creating releases. Since the @sentry/webpack-plugin uses unplugin, this indirectly makes the project require dependencies like vite, rollup and esbuild even though Nuxt 2 project doesn't use those.

skipLibCheck could be a solution for some but it's not ideal since it can hide real issues in the project.

Additional context

No response

Logs

No response

We temporarily closed this due to the lack of enough information. We could not identify whether it was a bug or a userland misconfiguration with the given info.
Please provide a minimal reproduction to reopen the issue.
Thanks.

Why reproduction is required

This is a generic issue and IMO doesn't really need a reproduction.

The core of the issue is that the package depends on various packages (rollup, vite, etc) without explicitly defining those as being its dependencies or peer dependencies. This in itself is a flaw in its design IMO.

And yes, I understand that given how NPM works, it's more or less impossible to find a perfect solution for this problem but it still be recognized as a problem. Even if the issue only manifests itself on the type side rather than runtime. (And feel free not to recommend enabling skipLibCheck since that's more of a copout).