Monorepo project dedupes dependencies even when not specified

[filipw01]

Describe the bug

I am using a monorepo package and an app consuming it. They both use different versions of a dependency

Vite uses the version specified in app, even when importing it from the internal package

I expect Vite to use version of a package that is specified in internal package's package.json for the package and the version in app's package.json for app code (not the package code)

For me personally it happens with yarn 3, but I reproduced it on stackblitz using pnpm
To represent the issue I used:
nanoid@2.0.0 for package that is using default export
nanoid@3.0.0 for app that is using named export

Reproduction

https://stackblitz.com/edit/github-zdg7ym-1hbqbp?file=package%2Findex.jsx

System Info

Note, this is my local system info where it failed with yarn, I wasn't able to run it in stackblitz

  System:
    OS: macOS 13.0
    CPU: (10) x64 Apple M1 Max
    Memory: 469.47 MB / 32.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 14.18.2 - ~/Library/Caches/fnm_multishells/926_1661596049762/bin/node
    Yarn: 3.2.3 - ~/Library/Caches/fnm_multishells/926_1661596049762/bin/yarn
    npm: 8.5.4 - ~/Library/Caches/fnm_multishells/926_1661596049762/bin/npm
  Browsers:
    Brave Browser: 104.1.42.86
    Chrome: 104.0.5112.101
    Firefox: 103.0.2
    Safari: 16.0
  npmPackages:
    @vitejs/plugin-react: 3.1.0 => 3.1.0
    vite: 4.1.2 => 4.1.2

Used Package Manager

yarn

Logs

Click to expand!

Error in browser ```shell Uncaught SyntaxError: import not found: default ```

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 vuejs/core 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.

[filipw01]

Most likely related to an issue that didn't have reproduction #8440

[FezVrasta]

This seems related to the package manager more than Vite?

[filipw01]

I don’t think so. I already reproduced it with 2 different package managers (pnpm and yarn 3), the first two I tried. This issue might also be related to #3254

[filipw01]

I added rollup as a counterexample. It handles two different package versions just fine. Can someone confirm this is a bug? I can try to work on that

[bluwy]

This might be fixed by #11410, which I'm working on rebasing it.

[gdosherjc]

Just wanted to pop in and confirm I'm seeing the same issue. Seems like bluwy is working on it though :)

Here is a summary of my pnpm workspace's packages dependencies. If I need to make a reproduction repo I can

apps/web-app:
    somePackage@1.x
    subPackageA@workspace
    subPackageB@workspace
// dev dependencies
    "@vitejs/plugin-legacy": "^4.0.0",
    "@vitejs/plugin-vue2": "^1.1.2",
    "vite": "4.3.0-beta.4",

packages/subPackageA
-- somePackage@1.x

packages/subPackageB
-- somePackage@0.x

When running vite:

Expectation: In subPackageB, I'd expect it to be using somePackage@0.x as that is what is defined in that packages package.json

Actual: Whatever version of somePackage that is installed in the application is what will be used for all packages. So when the web-app is set to @1.x, both subPackageA and subPackageB use that (even though subPackageB depends on v0.x.

Note: This only happens in dev mode. When I run vite build and then vite preview, both packages resolve how I'd expect and are working.

[sjmarshy]

Hi, I'm currently running into this issue!

Is there a workaround or solution in the meantime that hasn't been mentioned here?

I'm not sure what the status of the fix is, but the linked MR has been closed and no new ones are linked so I can't easily follow up elsewhere

[bluwy]

Sorry, I haven't finished it up since I last worked on that. The whole code path to deduplicate the packages turned out to be harder than expected if we want to preserve the performance. At the moment, I think this can be workaround (following gdosherjc's comment) with something like:

optimizeDeps: {
  include: [
    'subPackageA > somePackage'
    'subPackageB > somePackage'
  ]
}

So it keeps two reference. I have not tested this though.

[paul-sachs]

I think I'm also running into this same issue. In my case, I'm trying to migrate to @tanstack/react-query@5 from v4. I couldn't get the workarounds working at all, though it may be me not quite understanding how the ">" character is being interpreted here.

I've made a monorepo package called "@shared/query" which reexports the api from react-query. I've tried the following but nothing changed:

optimizeDeps: {
  exclude: ["@shared/query > @tanstack/react-query"]
}

Maybe I'm doing something wrong... 🤷

The workaround that did work was to rename the dependency itself, which you can do with pnpm with something like this in your package.json:

{
  "new-tanstack-react-query": "npm:@tanstack/react-query@5.13.4",
}

Then you just need to update references to new-tanstack-react-query within @shared/query which is pretty light touch.