Skip to content

[Bug Report] Tests using components with v-menu break with: TypeError: Cannot read property 'dark' of undefined #5096

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

Closed
laliluna opened this issue Sep 15, 2018 · 4 comments
Labels
testing upstream Problem with a third party library that we may have to work around wontfix The issue is expected and will not be fixed

Comments

@laliluna
Copy link
Contributor

Versions and Environment

Vuetify: 1.2.3
Last working version: 1.1.15
Vue: 2.5.17
Browsers: Firefox 61.0
OS: Mac OS 10.13

Steps to reproduce

Run yarn unit:test

======================
Original thread: #4987

This happens when testing:

[Vue warn]: Error in config.errorHandler: "TypeError: Cannot read property 'dark' of undefined"
TypeError: Cannot read property 'dark' of undefined

This happens when you attempt to mount any vue component that uses v-select:

wrapper = mount(Invite, {store, localVue, propsData: props, attachToDocument: true});

The actual code in the component:

<v-select
id="role"
v-bind:items="this.roles"
v-model="form.data.role"
label="Select user role"

The error is thrown at v-menu component on line: 211 which contains the following:

props: {
provide: {
theme: { isDark: this.$vuetify.dark || this.dark }
}
}

Versions and Environment

Vuetify: 1.20 or 1.21
Vue: 2.5.17
Browsers: N/A
OS: MacOS
Previously worked in:

Vuetify: 1.15
Vue: 2.5.17
Steps to reproduce

Attempt to test any component containing v-select using vue-dev-tools using the above mentioned versions.

Expected Behavior

to not throw the exception

Actual Behavior

throws exception [Vue warn]: Error in config.errorHandler: "TypeError: Cannot read property 'dark' of undefined"

Reproduction Link

https://github.com/laliluna/vuetify-bug-demo

Other comments

The weired thing is that I tried to create a codesandbox demo first but appearently it works in this environment.
See: https://codesandbox.io/s/201063371r

@lzhoucs
Copy link

lzhoucs commented Sep 20, 2018

I run into the same issue today and the following workaround worked for me:

// use
Vue.use(Vuetify)
// rather than
// localVue.use(Vuetify)

I was inspired by #4068 (comment) although the issue there seems not directly related to this one.

@umbertooo
Copy link

umbertooo commented Sep 26, 2018

I experienced the same behaviour with Vuetify version 1.2.4 and solved it the same way as @lzhoucs posted above. But even with this workaround the test happens to log a lot [Vue warn]:... warnings. These logs could be suppressed using this snippet:
#3456 (comment)

While these workarounds may be acceptable temporarily I'd expect to use the Vuetify like every other Vue.js plugin with the Vue Test Utils (https://vue-test-utils.vuejs.org/guides/common-tips.html#applying-global-plugins-and-mixins) meaning using localVue.use(Vuetify) instead of Vue.use(Vuetify).

@ascott18
Copy link
Contributor

Any updates on this? Would be great to be able to do localVue.use(Vuetify) since it is the officially prescribed method for testing Vue components.

@KaelWD
Copy link
Member

KaelWD commented Dec 19, 2018

See #4068 and vuejs/vue#8278, it's a problem with vue that was uncovered when we switched to typescript. There's nothing wrong with not using localVue, that's how it worked with avoriaz before vue-test-utils was a thing.

@KaelWD KaelWD closed this as completed Dec 19, 2018
@KaelWD KaelWD added wontfix The issue is expected and will not be fixed upstream Problem with a third party library that we may have to work around labels Dec 19, 2018
@lock lock bot locked as resolved and limited conversation to collaborators Dec 19, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
testing upstream Problem with a third party library that we may have to work around wontfix The issue is expected and will not be fixed
Projects
None yet
Development

No branches or pull requests

6 participants