cypress: Component spec file not found by runner (runner uses full path?) - GET /__cypress/iframes/... 404

Current behavior

When component testing, Cypress does not seem to be able to load the spec file contents. Cypress does list my spec file, but when I click to run it it keeps infinitely loading.

URL in my Cypress window:

http://localhost:3036/__/#/specs/runner?file=cypress/component/example.cy.js

What I see in my console:

GET /__cypress/iframes//Users/<me>/<path/to/repo>/cypress/component/example.cy.js 404 2.497 ms - -

Perhaps this has something to do with the fact that it seems to attempt to load a full path, starting from the root /Users directory. When I run my e2e tests the same GET request in my console lists a path relative to the current repo.

Screenshots

List of all specs: Screen Shot 2022-06-24 at 10 45 09 AM

Infinitly loading spec details: Screen Shot 2022-06-24 at 9 58 13 AM

Desired behavior

Find the spec file and run it, just like my e2e tests 😁

Test code to reproduce

// cypress.config.js
const { defineConfig } = require("cypress");

module.exports = defineConfig({
  component: {
    devServer: {
      framework: "react",
      bundler: "vite",
    },
    specPattern: "cypress/component/**/*.cy.{js,jsx,ts,tsx}",
  },
});

// example.cy.js
import Example from "../../app/frontend/components/Example/Example"

describe('<Example>', () => {
  it('mounts', () => {
    cy.mount(<Example />)
  })
})

Cypress Version

10.2.0

Other

No response

About this issue

Original URL
State: closed
Created 2 years ago
Reactions: 3
Comments: 56 (27 by maintainers)

Most upvoted comments

I’ve found the source of the problem. Everything starts with iframes/* handling:

https://github.com/cypress-io/cypress/blob/b08bc270e90db72e7bdafc4eb80cc38c8463ccb1/packages/server/lib/routes.ts#L66-L74

It delegates to here where it proxies to a path that uses devServerPublicPathRoute as the base: https://github.com/cypress-io/cypress/blob/b08bc270e90db72e7bdafc4eb80cc38c8463ccb1/packages/server/lib/controllers/iframes.ts#L44-L50

In the configuration step, it sets base of the Vite config to devServerPublicPathRoute:

https://github.com/cypress-io/cypress/blob/688b7ea33e8243a76fc1b3bd7f5ef7f2bfba07f9/npm/vite-dev-server/src/resolveConfig.ts#L49-L51

Everything seems fine until here. However, the Vite config gets merged using vite.mergeConfig where the configuration defined by Cypress can be overridden by another user/framework configuration:

https://github.com/cypress-io/cypress/blob/688b7ea33e8243a76fc1b3bd7f5ef7f2bfba07f9/npm/vite-dev-server/src/resolveConfig.ts#L113

So, if base is defined in the user’s Vite config, it will not be overridden by Cypress. But, Cypress doesn’t actually expect that to happen, so everything breaks.

Quasar sets it here: https://github.com/quasarframework/quasar/blob/a01d8132272a6470940c813d6eeb47da216f1574/app-vite/lib/config-tools.js#L96-L99

Laravel sets it here: https://github.com/laravel/vite-plugin/blob/8fbb885eb7650d7555e3e5c8aff0dcf0c4167d70/src/index.ts#L123-L124

Vite Ruby sets it here: https://github.com/ElMassimo/vite_ruby/blob/08815045216f9d2fb337486e541eff2ad558d2f5/vite-plugin-ruby/src/index.ts#L63-L65

Solutions

One of the following ways can be chosen:

Make it impossible to override base or similar options on which Cypress highly depends.
- This might cause some problems where a Vite plugin automatically transforms resources in HTML files to use a certain base path(/x.js -> custom/base/x.js).
Document this behavior and expect users or tooling authors to unset base before passing it to Cypress. Doesn’t sound fair to me as a user. But, at least everyone can use this approach as a workaround. We will utilize this workaround in https://github.com/quasarframework/quasar-testing, see https://github.com/quasarframework/quasar-testing/pull/259#discussion_r994857387
Use the base from finalized Vite config when proxying or doing similar operations. Probably the best solution for users, not sure about maintainers.

yusufkandemir on Oct 13, 2022

ANY updates / additional info on this? ANY idea where the problem resides, or how to work around it?

@jessevdp @thunder809 @lmiller1990 I’ve been having the same issue with a Laravel project using Vite and Vue. The solution for me was to disable the laravel-vite-plugin while running cypress tests. I found the idea from this project that was given as a talk at Laracon: https://github.com/beyondcode/laragone/blob/main/vite.config.js

The config is just set up to ignore the plugins it doesn’t need when running cypress tests.

Censin on Sep 28, 2022

Yes of course! I will set up you a minimal repo, as soon as i´m back to work on monday!

thunder809 on Jul 30, 2022

@Tpict thanks for this - it’s useful to know. I’m not actively looking into this right now, but I’d like to revisit it soon. This should be helpful for myself or others debugging this.

lmiller1990 on Jul 18, 2022

@lmiller1990 My suspicion is now that we have two separate issues, as actually my problem does not include the error message on the same screen (I get it when requesting the .cy.ts file while testing) and I have run a profiling session to find no apparent network errors. I’ll try to find some distinguishing factor in my issue so I can know for sure, but until then probably disregard the details I’ve shared.

TPHRyan on Jun 30, 2022