-
-
Notifications
You must be signed in to change notification settings - Fork 6.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Vite can use the wrong module if local or linked modules include their own node_modules
, breaking Vue
#7454
Comments
I haven't tested the repro, but would |
This does indeed resolve the issue, thank you for the pointer! Since this is really only a problem with local packages during development, is this expected behavior and would this be considered the recommended way to address this issue? I think my concern is that, for peer dependencies, Vite is following the same path as regular dependencies when building the module graph, which I think doesn't match how NPM models peer dependencies. |
Maybe it makes sense for |
A comment. Nuxt emits ESM output. And the
see vite/packages/vite/src/node/plugins/ssrRequireHook.ts Lines 51 to 65 in 0ebeb98
This means that enabling this by default would break Nuxt, unless we remove the ssr-require-hook or tweak it to respect ESM output. |
Similar problem with running preact app and a react ui library in one monorepo. react alias gets resolved to |
Fixes vitejs#2443 Fixes vitejs#7454 It's already been set by default in Nuxt 3 for a while now nuxt/framework#6735 So I think this change should be harmless. And technically it could be considered a fix than a feat. Nevertheless, it's better to ship it in v4 to minimize disruptions on the user side. Things that are not covered in this PR: 1. SSR, because `resolve.dedupe` doesn't work for ESM build outputs, and the CommonJS version is kinda hacky, I think it's better to skip the config for SSR completely. Besides, most related issues are from the client side. 2. #5958 isn't fixed by this PR.
Describe the bug
I am building a UI library package and a Vue app at the same time. Both projects are following best practices from Vite. The UI package and the Vue app both rely on Headless UI.
If the UI package is linked or added as a local file, the
node_modules
folder comes along with thedist
folder. When this happens, Vite will analyse thenode_modules
folder within the UI package first to resolve Headless UI, which I think grabs a separate instance of Vue and results in errors likeprovide() can only be used inside setup()
.Evidence from the logs below:
Ideally
@headlessui/vue
should resolve to the one in in/website
instead of/ui-library
.Reproduction
https://github.com/JeffSchofield/vite-module-bug
System Info
Used Package Manager
npm
Logs
Validations
The text was updated successfully, but these errors were encountered: