Deps Pre-optimization does not exclude nested deps

[antfu]

Describe the bug

For example, we have @vueuse/core relying on vue-demi, if we exclude the optimization for vue-demi (but not @vueuse/core) via

optimizeDeps: {
  exclude: [
    'vue-demi'
  ]
}

Which the nested vue-demi does not been excluded from the optimized bundle for @vueuse/core. Causing the potential duplication for deps.

Related nuxt/bridge#186

Reproduction

(Just creating a quick issue for tracking, will fulfill the repro and make the PR soon)

System Info

-

Used Package Manager

pnpm

Logs

No response

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to https://github.com/vuejs/vue-next instead.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[bluwy]

I can confirm this too. I had always assumed this to be intentional since prebundling is always necessary for third-party libraries. Or it would cause the duplication issue as mentioned. Is there a reason to exclude vue-demi? (I'm not familiar with the current state of Nuxt)

[antfu]

Some packages might be relying on the internal singleton states (in my case is @vue/composition-api). Just imagining

import Vue from 'vue'

Vue.use(SomePlugin)

import Vue from 'vue'

Vue.$someplugin() // if the `vue` is not the same vue, it will failed.

So I guess at least we should support something like: (similar to the include pattern https://vitejs.dev/config/#optimizedeps-exclude)

optimizeDeps: {
  exclude: [
    '* > vue-demi'
  ]
}

[bluwy]

We also had the same singleton issue for Svelte as well. The solution was to force optimizeDeps.include on svelte, so the prebundled code essentially deduped it. I think the code example can be fixed the same way as well by adding vue to optimizeDeps.include. I'm not entirely clear why vue-demi is to be excluded 😅 but the exclude pattern is certainly a nice addition where needed.

[antfu]

Yeah, the problem is that we want to do some aliasing here so we have to opt-out of those dependencies. If we exclude one sub dependencies (vue-demi) which make all packages on top of it also be excluded from the optimization (otherwise it would still have duplications). From Nuxt's perspective, it's impossible to list all the packages relying on vue-demi or @vue/composition-api to exclude them out. Not only the performance might suffer for unbundled packages, it also means any new packages that are not on the exclusion list will break the app 😅

I will see what I can improve it and drop a PR soon

[TimvdEijnden]

Yeah, the problem is that we want to do some aliasing here so we have to opt-out of those dependencies. If we exclude one sub dependencies (vue-demi) which make all packages on top of it also be excluded from the optimization (otherwise it would still have duplications). From Nuxt's perspective, it's impossible to list all the packages relying on vue-demi or @vue/composition-api to exclude them out. Not only the performance might suffer for unbundled packages, it also means any new packages that are not on the exclusion list will break the app 😅

I will see what I can improve it and drop a PR soon

Hey @antfu Loved your talk 2 days ago :) But I'm also looking intro upgrading to nuxt 3.2 but I now also face the same issue.

SyntaxError: The requested module 'vue-demi' does not provide an export named 'default'

It's from a package which has vue-demi as a nested dependency.