@cypress/vue@4.0.0 bundle is broken: @vue/test-utils is not externalized

[0x009922]

Current behavior

Currently @cypress/vue (v4) has a dependency:

{
  "dependencies": {
    "@vue/test-utils": "2.0.0-rc.19"
  }
}

But if you explore actual dist/cypress-vue.*.js files, you will see that Vue Test Utils is not imported, but bundled. The only external import is vue.

Desired behavior

@cypress/vue should import @vue/test-utils, not bundle it.

Test code to reproduce

Bundle bug, not test code.

Cypress Version

10

Other

It is a huge problem because our tests rely heavily on setting global Vue Test Utils configuration to achieve global components registration per spec file. (https://test-utils.vuejs.org/api/#config-global)

For example, we do that trick:

import { config } from '@vue/test-utils'
import { mount } from '@cypress/vue'

before(() => {
  config.global.components = { SRadio, SRadioGroup }
})

after(() => {
  config.global.components = {}
})

it('just mounts', () => {
  cy.mount({ template: `<SRadioGroup />` })
})

Now it doesn't make any effect because mount() from @cypress/vue does not import @vue/test-utils, i.e. it is broken.

BTW, Cypress 10 is awesome!

[lmiller1990]

Hi! Good point. If we import it, though, it's an additional peer dependency, which isn't really ideal.

We've got two options:

1. try to import it, then defer to bundled version.
2. bundle it and re-export it

I think 2 is the best option - this way, you just need to update to the latest cypress version, and you'll get all the updates for free. cypress/vue is generally running against the latest stable test utils version.

This would mean you'd do

import { config, mount } from 'cypress/vue'

Also, if you are on Cypress 10, you don't even need to install @cypress/vue - we bundle it with Cypress, so just import it from cypress/vue. The goal is, instead of installing lots of different libraries, you just need to install and update Cypress, and we deal with the rest!

What do you think? Open to the first option too, but I think less peer dependencies is generally better for the end user, since you don't have to mess around with updating everything, just one dependency (cypress).

[Akryum]

At least if we can access the @vue/test-utils exports, it would be fine. Currently we can't upgrade to Cypress 10 because of this.

[JessicaSachs]

One of the issues to consider with either solution is that config is a Vue 3-only concept. When we document the solution, this is only gonna be applicable to Vue 3.

@Akryum what do you need from the exports object that you cannot set when invoking mount itself? The before/after syntax in the initial code example of this issue is useful, but it's entirely possible to just pass in global.components from within mount in a custom command.

[lmiller1990]

I am working on this, it should be done soon.

Edit: I made this PR #22757

What do you all think of this API? Basically, we just re-export @vue/test-utils as VueTestUtils, and you can do what you want. I don't see this as a "front and center" API, but more for power users familar with Test Utils who want more custom, fined grained control - as @JessicaSachs pointed out, you can already do this.

import { VueTestUtils, mount } from 'cypress/vue'
import Foo from './Foo.vue'

describe('VueTestUtils API', () => {
  before(() => {
    VueTestUtils.config.global.components = {
      'globally-registered-component': {
        setup () {
          return () => h('h1', greeting)
        },
      },
    }
  })

  it('gains access to underlying Vue Test Utils library', () => {
    mount(Foo)

    cy.get('h1').contains(greeting)
  })
})

There's probably some edge cases, and certain APIs between Test Utils v1 and v2 are different, so regarding docs, I think we'd just say "cypress/mount uses @vue/test-utils under the hood, which is exported as VueTestUtils. Some common things you might like to do such mounting global components can be done without using this export , but for advanced use cases and migrate purposes, the VueTestUtils export is also present".

I've also inlined the Test Utils type definitions, so those should be working (even for users with the @vue/test-utils library installed in node_modules).

[lmiller1990]

The PR is ready to go.

@Akryum will this solve your problem?

[Akryum]

Looking good