feat(npm/vue): expose Test Utils API

[lmiller1990]

• Closes @cypress/vue@4.0.0 bundle is broken: @vue/test-utils is not externalized #22611
• Closes cypress/{vue,react} type definitions broken - depend on unbundled deps #22138

User facing changelog

• Expose additional testing API from underlying Vue Test Utils library in the cypress/vue package.
• Inline @vue/test-utils type definitions, instead of relying on a peerDependency that might not be available, or the wrong version.

Additional details

Expose additional testing API from underlying Vue Test Utils library in the cypress/vue package.

cypress/vue uses @vue/test-utils under the hood. Generally, users won't need to access this library, but there are some scenarios for advanced users where it might be useful, or where they are migrating some older jsdom + jest tests to use Cypress.

Exposing the underlying library might be useful for those scenarios. See #22611 for an examples from the community.

Generally, in Cypress, we do global setup in a custom command. Some people may not like to use a custom command, or have some other use case in mind, so I think it's good to support alternative use cases, too.

I wouldn't consider this to be idiomatic - Cypress encourages use of custom commands where possible - so I don't think we will be recommending this in our main docs. Instead, I wrote a small note in the @cypress/vue README.

Inline @vue/test-utils type definitions

We bundle @vue/test-utils entirely in the cypress/vue code we ship in the binary. TypeScript has no such "inline the types" feature, though, so the generated type definitions would do import type {...} from '@vue/test-utils.

This would give you a typing error, if you don't install a peer dependency (which we don't technically require, so it's confusing for users). In this PR, I wrote a little script to grab the types from the monorepo's node_modules/@vue/test-utils/dist/**/*.d.ts and paste them in npm/vue/dist when we build the library. This will let users get correct type definitions without needing the peer dependency.

I also added some simple type tests to make sure it's working as expected.

Steps to test

1. Verify problem - install cypress from npm, do import { mount } from 'cypress/vue' and follow it to the type def
2. You'll see they reference a library, @vue/test-utils, which you probably don't have installed (for example on line 3).

This is a problem! Verify the fix:

1. Grab this branch
2. cd npm/vue
3. yarn build
4. Look in cli/vue/dist/index.d.ts

Observe it's now referring to relative types - note the './ in from of ./@vue/test-utils on line 3:

As for exposing the VueTestUtils API, you can see the test:

https://github.com/cypress-io/cypress/pull/22757/files#diff-f9a3bc77ab97b5f10f220de6ab30201be456aad25cb85e8197c52b2b90959684

How has the user experience changed?

PR Tasks

• Have tests been added/updated?
• Has the original issue (or this PR, if no issue exists) been tagged with a release in ZenHub? (user-facing changes only)
• Has a PR for user-facing changes been opened in cypress-documentation?
• Have API changes been updated in the type definitions?

[cypress-bot]

Thanks for taking the time to open a PR!

• Create a Draft Pull Request if your PR is not ready for review. Mark the PR as Ready for Review when you're ready for a Cypress team member to review the PR.
• Become familiar with the Code Review Checklist for guidelines on coding standards and what needs to be done before a PR can be merged.

[cypress]

---

Test summary

37721 • 0 • 456 • 0 • 13

---

Run details

Project	cypress
Status	Passed
Commit	834c475
Started	Jul 16, 2022 1:50 AM
Ended	Jul 16, 2022 2:07 AM
Duration	17:00 💡
OS	Linux Debian - 10.11
Browser	Multiple

View run in Cypress Dashboard ➡️

---

Flakiness

	actions/click.cy.js		1
1	... > scroll-behavior > can scroll to and click elements in html with scroll-behavior: smooth
	xhr.cy.js		4
1	... > logs request + response headers
2	... > logs Method, Status, URL, and XHR
3	... > logs response
4	... > logs request + response headers
This comment includes only the first 5 flaky tests. See all 13 flaky tests in the Cypress Dashboard.

---

This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard

[mike-plummer]

Is this really a TODO anymore? Seems like maybe just a comment is needed to explain why we're exporting even though it doesn't make a ton of sense for Cy

[marktnoonan]

Yeah I totally agree with exposing it for easy migration and keeping tests as close as possible before and after. Folks can modify their tests as a separate step when they have the need to see their components render fully.

[lmiller1990]

Look carefully - we are not exposing it:

const {
  mount: VTUmount,
  // TODO: Should we expose shallowMount? It doesn't make much sense in the context of Cypress
  // but it might be useful for people who like to migrate some Test Utils tests to Cypress.
  shallowMount,
  ...VueTestUtils
} = _VueTestUtils

export { VueTestUtils }

We destructure the properties we do not want to expose, and the rest are in the remaining ...VueTestUtils object, which we export.

We should not expose shallowMount imo, since Cypress is supposed to encourage production-like testing, and shallowMount leads to all kind of weird, impossible-in-production scenarios.

We could expose it for migration purposes, I'd prefer to wait for someone to ask for this, though. I generally think we shouldn't expose it, since

• React and Angular don't have something similar
• If you do a shallowMount, most of Cypress (cy.get etc) won't work, since everything is stubbed out.

[lmiller1990]

@mike-plummer I will remove TODO and just say the reason we don't expose it.

[lmiller1990]

Done!

[cypress-bot]

Released in 10.3.1.

This comment thread has been locked. If you are still experiencing this issue after upgrading to
Cypress v10.3.1, please open a new issue.