Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

Vue acts different locally than production #12

Closed
7 tasks done
mmeester opened this issue Dec 3, 2021 · 5 comments
Closed
7 tasks done

Vue acts different locally than production #12

mmeester opened this issue Dec 3, 2021 · 5 comments
Labels
Inconsistency Inconsistency between dev & build

Comments

@mmeester
Copy link

mmeester commented Dec 3, 2021

Describe the bug

I have written a Vue 3 package with a component and a composable, the component uses the composable for logic and is exposed outside the app to be used on other parts of the actual application.

Vite Demo

The code of the implementation can be found here: https://github.com/mmeester/component-composable-demo

Expected behaviour
The state inside and outside the component is changed synchronous (reactive),

Actual local behaviour
❌ Both states are separated and change independently

Build / Production behaviour
✅ Works as expected and can be viewed here: https://unruffled-newton-d68d59.netlify.app/

Vue-CLI

I've also tried to run the same example with the vue CLI to see if this has anything to do with vue or particularly with vite. The code of the vue-cli can be found here: https://github.com/mmeester/component-composable-vue-demo

Expected behaviour
The state inside and outside the component is changed synchronous (reactive),

Actual local behaviour
✅ Works as expected

Build / Production behaviour
✅ Works as expected and can be viewed here: https://hopeful-sammet-11ef56.netlify.app/

Reproduction

  1. Clone repo on: https://github.com/mmeester/component-composable-demo
  2. npm i
  3. npm run dev
  4. open in browser and see mismatch in states

System Info

System:
    OS: macOS 12.0.1
    CPU: (10) arm64 Apple M1 Max
    Memory: 3.05 GB / 64.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 16.13.0 - ~/.nvm/versions/node/v16.13.0/bin/node
    Yarn: 1.22.15 - ~/.nvm/versions/node/v16.13.0/bin/yarn
    npm: 8.1.4 - ~/.nvm/versions/node/v16.13.0/bin/npm
  Browsers:
    Chrome: 96.0.4664.55
    Edge: 96.0.1054.43
    Firefox: 94.0.2
    Safari: 15.1
  npmPackages:
    @vitejs/plugin-vue: ^1.9.3 => 1.10.1
    vite: ^2.6.4 => 2.6.14

Used Package Manager

npm

Logs

No response

Validations

@haoqunjiang haoqunjiang added the Inconsistency Inconsistency between dev & build label Dec 4, 2021
@poyoho
Copy link
Member

poyoho commented Dec 5, 2021

Because your package depends on vue, rebuilding vue causes the two component states not to share.

vite will pre-bundled packages, and the dependent packages do not declare dependent vue, so vite will rebuilding vue.

  • will ignore your package on pre-bundled
export default defineConfig({
  plugins: [vue()],
  optimizeDeps: {
    exclude: [
      'component-composable'
    ]
  }
})

@mmeester
Copy link
Author

mmeester commented Dec 6, 2021

Thanks @poyoho this fixes the issue, wonder if this should be documented somewhere.

@bluwy
Copy link
Member

bluwy commented Mar 29, 2022

Possibly related to #26 and vitejs/vite#7454 (comment). I wonder if resolve.dedupe: ['vue'] would fix this too.

@bluwy

This comment was marked as outdated.

@bluwy bluwy closed this as completed Jun 26, 2022
@bluwy

This comment was marked as outdated.

@bluwy bluwy reopened this Jun 26, 2022
haoqunjiang referenced this issue in haoqunjiang/vite Nov 22, 2022
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.
@haoqunjiang haoqunjiang transferred this issue from vitejs/vite Dec 3, 2022
@vitejs vitejs locked and limited conversation to collaborators Sep 25, 2024
@edison1105 edison1105 converted this issue into discussion #453 Sep 25, 2024

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
Inconsistency Inconsistency between dev & build
Projects
None yet
Development

No branches or pull requests

4 participants