Vue testing library depends on vuex and vue-router types

[sapagat]

Hi there! For my surprise importing the @testing-library/vue module raises a compilation error due to a dependency with vue-router and vuex.

 ERROR  Failed to compile with 2 errors

These dependencies were not found:

* vue-router in ./node_modules/@testing-library/vue/dist/vue-testing-library.js
* vuex in ./node_modules/@testing-library/vue/dist/vue-testing-library.js

To install them, you can run: npm install --save vue-router vuex
  [=========================] 100% (completed)

 WEBPACK  Failed to compile with 2 error(s)

Error in ./node_modules/@testing-library/vue/dist/vue-testing-library.js

  Module not found: 'vue-router' in '/home/sam/sandbox/opencocos/app/node_modules/@testing-library/vue/dist'

Error in ./node_modules/@testing-library/vue/dist/vue-testing-library.js

  Module not found: 'vuex' in '/home/sam/sandbox/opencocos/app/node_modules/@testing-library/vue/dist'

I've tried installing both dependencies and test pass, but I believe it shouldn't be mandatory in order to run tests, right?

Notice: I'm not using Jest. I'm running tests with Mocha.

[afontcu]

Hi! Yes it does, because VTL accepts a routes and store objects, which autoloads Router and Vuex: https://github.com/testing-library/vue-testing-library/blob/master/src/vue-testing-library.js#L36-L49

I once thought that they should be listed as peerDeps, but since they are only required if these keys are there… 

[sapagat]

I've double checked and no routes nor store are passed to the render method. It may be a webpack issue that detects the packages being required?

I've bypassed the issue by requiring both packages in order to use VTL. I believe it should be optional, and currently it isn't. Don't know how to solve it... =(

[afontcu]

Hm, can you share the test that makes both deps fail?

[vfritzon]

Hi!

I think I've run into this issue as well.

I get

ERROR in [...]/node_modules/@testing-library/vue/types/index.d.ts(5,35):

5:35 Cannot find module 'vuex' or its corresponding type declarations.

    3 | import Vue, {ComponentOptions} from 'vue'

    4 | import {ThisTypedMountOptions, VueClass} from '@vue/test-utils'

  > 5 | import {Store, StoreOptions} from 'vuex'

      |                                   ^

    6 | import Router, {RouteConfig} from 'vue-router'

    7 | // eslint-disable-next-line import/no-extraneous-dependencies

    8 | import {

in a ts project that does not have a dependency on vuex. It builds if I add vuex as dep.

[K-Schaeffer-LOG]

Having similtar issue with vue-router. The project doesnt have a dependency on it, still the following error happens on build:

6:35 Cannot find module 'vue-router' or its corresponding type declarations.
    4 | import {ThisTypedMountOptions, VueClass} from '@vue/test-utils'
    5 | import {Store, StoreOptions} from 'vuex'
  > 6 | import Router, {RouteConfig} from 'vue-router'
      |                                   ^
    7 | // eslint-disable-next-line import/no-extraneous-dependencies
    8 | import {
    9 |   queries,

[K-Schaeffer-LOG]

I just added vue-router as a development dependency and the build went fine.
This is a workaround, but It's not a good one.. We might need a fix to the root cause.

[afontcu]

Looks like it is due to VTL types making use of TS definitions from both Router and Vuex. Not sure how to fix this one – maybe simply copy&pasting these types from both libraries into VTL, so that the dependency can go?

https://github.com/testing-library/vue-testing-library/blob/master/types/index.d.ts#L3-L6

[afontcu]

Took a look, and types we're getting from Vuex and Vue Router are quite complex and verbose. We'd be copy&pasting a huge chunk of Router/Vuex types… not entirely sure this is benefitial over installing two deps (that could be defined as devDep).

thoughts?

[K-Schaeffer]

I'm not sure If all types are needed, we might add a few to stop the error and that's It.

But I'm not sure, as far as I see VTL shouldn't rely on those types in any way.

[afontcu]

I'm not sure If all types are needed, we might add a few to stop the error and that's It.

Wouldn't that generate several warnings on loose types if we change the complex ones to any, for instance? no-unsafe-assignment or no-unsafe-call being some of them.

as far as I see VTL shouldn't rely on those types in any way

Would you define store and routes as any (or anything similar) and call it a day?

[afontcu]

Is there a best way? I really don't want to copy and maintain a ton of Router/Vuex types, and loosen them up doesn't feel right, either: #246