-
Notifications
You must be signed in to change notification settings - Fork 262
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
Bug: findComponent
doesn't not return exposed properties in vm if component is bundled
#2591
Comments
This indeed looks like a bug if it works with mount but not with findComponent. |
@cexbrayat ok, i'll give it a try :) |
Nope still doesn't work for all cases. |
Should we do this
…the vm even when that instance does not have a templateRef?
@cexbrayat i've spend way more time on this than I should and yet I don't think I know exactly why it happens. 😛 Why
|
const [result] = this.findAllComponents(selector) | |
return result ?? createWrapperError('VueWrapper') |
And there, we return the proxy to
createVueWrapper
which does not have the exposed
properties by design **if using <script setup>
. I know this because before calling .map
results is a ComponentInternalInstance[]
which has all the properties including exposed
properties. but we need to provide the proxy to createVueWrapper
here or a lot of tests will fail.Lines 215 to 222 in 2f19fdf
const results = find(currentComponent.subTree, selector) | |
return results.map((c) => | |
c.proxy | |
? createVueWrapper(null, c.proxy) | |
: createDOMWrapper(c.vnode.el as Element) | |
) | |
} |
I've made a hacky fix draft by assining the exposed properties via root chain to this.componentVM
or via createVMProxy
and added tests and double check tests for all scenarios (even added the mount tests (which I believe you kind already do in expose.spec.js
) because the truth is that I don't know how to make a good one or even if we should do it.
Todo/ not todo
- it looks like against
expose/defineExpose
design thatfindComponent(Component)
to include exposed properties in thevm
— even if$parent/$root
chain access mentioned in the docs seems leave a door open for it. - At the same time, current VTU behaviour is inconsistent as per my reproduction demo. If
findComponent(Component)
includes exposed properties from a<script setup>
component template direct import, it should also do it for it's explicitly bundled or runtime render function counterparts.
Anyways here's draft here, but I need help/guidance.
Cheers, have a nice weekend!
Describe the bug
This is a bit hard to describe but hopefully the reproduction demo will clear things up.
I have a big project with 7000+ thousand tests. Recent ones are good, old ones are bad and rely heavily on
.vm
.I'm migrating the code base to a monorepo and the design system is now bundled as separate package by
vite
and the apps import the components’ bundled version instead of the.vue
, tests inherently do too. I noticed that most of the tests that rely onvm
stopped working.Note
I don't know if this is
VTU
fault or if it's by design, but having in mind that if I import the raw.vue
component instead of the bundled.js
version everything works I am assuming it is — Please close this issue if my assumption is wrong.To Reproduce
https://stackblitz.com/edit/vitest-dev-vitest-h8drorow?file=apps%2Fdemo%2Ftest%2Fbasic.test.ts
Should run automatically, if not
npm run test
Expected behavior
exposed properties via
defineExpose
are available though offindComponent
returnedVueWrapper
Assuming a basic
VExample.vue
componentBundles to
Faulty test
Related information:
Additional context
The same behaviour is not found in
mount
. When passing the bundled version of a component tomount
, exposed properties are exposed correctly to vm, that's why I think it's a bug infindComponent
.The text was updated successfully, but these errors were encountered: