Local and transitive dependencies resolved into different "instances" in dev mode

pr0da commented 2 years ago

Describe the bug

Take the following dependency structure:

my-project
  - dep-a@1.0.0
  - dep-b
     - dep-a@1.0.0

dep-a should resolve to the same "instance" whether I access it directly (import depA from 'dep-a') or indirectly via dep-b (e.g when it re-exports members from dep-a or returns a dep-a object, etc).

In dev mode this does not seem to be the case. I got back two separate "instances" from the same package, with the same version.

See the attached example where dep-a is luxon@1.28.0 and dep-b is cron-parser@4.3.0".

I think this is a regression in 2.9.0:

vite@2.9.1: example: different behaviour in prod and dev mode

dev mode: the DateTime instances are different (different prototype, constructor name, etc)
prod mode: works as expected, local and transitive code share the same DateTime instance

vite@2.8.6: example: works as expected

dev/prod mode: identical, local and transitive code share the same DateTime instance

Luxon resolves to the same version (yarn why luxon):

├─ cron-parser@npm:4.3.0
 │  └─ luxon@npm:1.28.0 (via npm:^1.28.0)
 │
└─ my-project@workspace:.
   └─ luxon@npm:1.28.0 (via npm:^1.28.0)

Reproduction

https://stackblitz.com/edit/vitejs-vite-n3tocb?file=package.json

System Info

System:
    OS: macOS 12.3.1
    CPU: (8) arm64 Apple M1
    Memory: 179.31 MB / 16.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 16.14.0 - ~/.nvm/versions/node/v16.14.0/bin/node
    Yarn: 3.2.0 - ~/.nvm/versions/node/v16.14.0/bin/yarn
    npm: 8.3.1 - ~/.nvm/versions/node/v16.14.0/bin/npm
  Browsers:
    Chrome: 100.0.4896.75
    Safari: 15.4
  npmPackages:
    vite: 2.9.1 => 2.9.1

Used Package Manager

yarn

Logs

No response

Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] 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/core instead.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

sapphi-red commented 2 years ago

It is working well with 2.9.0-beta.7, but not with 2.9.0-beta.8. I think #7438 is affecting this. The reason is simillar to #7721, #7736.

pr0da commented 2 years ago

@sapphi-red any update?

I've re-checked with the latest stable (2.9.12) and alpha (3.0.0-alpha.14) versions and it's still broken. This is kind of a deal breaker for us to upgrade and we stuck at 2.8.6.

It basically breaks libraries like luxon if any dependency also depends on / uses it. You can't use luxon instances interchangeably (eg. DateTime.isDateTime() will return false for DateTime instances created by the dependency).

I want to emphasise that this is DEV only, which also raises some concerns e.g.: different behaviour in prod / dev environment for the same code base.

Thanks for the update!

sapphi-red commented 2 years ago

@pr0da There isn't any.

FYI I have found this workaround works.

export default {
  resolve: {
    alias: {
      luxon: 'luxon/build/node/luxon.js'
    }
  }
}

codeart1st commented 1 year ago

Have the same problem with two instances of framer-motion, which breaks exit animations in dev mode

vitejs / vite