Support vite v5 for component testing #28347

MikeMcC399 · 2023-11-16T11:25:23Z

What would you like?

Cypress component testing should support vite v5 (React, Vue and Svelte) - see announcement Vite 5.0 is out! Nov 16, 2023.

Why is this needed?

According to https://docs.cypress.io/guides/component-testing/overview "Vite 2+" is supported, however in practice only up to Vite v4 is supported by Cypress 13.x at this time.

cypress/packages/scaffold-config/src/dependencies.ts

Lines 73 to 80 in ab60af8

    
           export const WIZARD_DEPENDENCY_VITE = { 
        
             type: 'vite', 
        
             name: 'Vite', 
        
             package: 'vite', 
        
             installer: 'vite', 
        
             description: 'Vite is dev server that serves your source files over native ES modules', 
        
             minVersion: '^2.0.0 || ^3.0.0 || ^4.0.0', 
        
           } as const

Other

See Migration from (vite) v4 and note that the CJS Node API has been deprecated.

The text was updated successfully, but these errors were encountered:

MikeMcC399 · 2023-12-09T12:53:25Z

Following the steps to reproduce on vite.config missing after CT onboarding - unexpected error #26849, which installs the latest version of vite, results in the warning:

The CJS build of Vite's Node API is deprecated. See https://vitejs.dev/guide/troubleshooting.html#vite-cjs-node-api-deprecated for more details.

This is also noted in the issue [CT] Fix Vite 5 CJS Deprecation Warning and Prepare for Vite 6 #28373

MikeMcC399 · 2023-12-11T16:43:37Z

@jordanpowell88

The examples in cypress-io/component-testing-quickstart-apps are left using vite@4.5.1 until this enhancement request is addressed.

rstoneIDBS · 2023-12-11T18:01:49Z

I'm currently experiencing issues with component testing when trying Vite 5.0.7 with Cypress 13.6.1. It looks like 'public' folder mapping is broken which (for me anyway) breaks the use of mock service worker amongst other things. Is this likely to be fixed by the work mentioned in this ticket or would you like a new issue raised?

juliandreas · 2023-12-19T12:18:44Z

I'm currently experiencing issues with component testing when trying Vite 5.0.7 with Cypress 13.6.1. It looks like 'public' folder mapping is broken which (for me anyway) breaks the use of mock service worker amongst other things. Is this likely to be fixed by the work mentioned in this ticket or would you like a new issue raised?

Same.

MikeMcC399 · 2023-12-19T12:26:35Z

@rstoneIDBS / @juliandreas

Did you try using the latest Vite version v5.0.10?

juliandreas · 2023-12-19T12:49:48Z

Did you try using the latest Vite version v5.0.10?

Yep.

MikeMcC399 · 2023-12-19T12:55:30Z

For comparison PR chore: support vite v4 for component testing #25365 from @marktnoonan which updated the support to Vite v4. Perhaps somebody has an idea what needs to be done to update to Vite v5 support?

rstoneIDBS · 2024-01-02T10:42:10Z

Just tried again with the latest versions of Cypress (13.6.2) and Vite (5.0.10) and I'm still seeing the same issue.

steveworkman · 2024-01-03T11:30:19Z

I'm currently experiencing issues with component testing when trying Vite 5.0.7 with Cypress 13.6.1. It looks like 'public' folder mapping is broken which (for me anyway) breaks the use of mock service worker amongst other things. Is this likely to be fixed by the work mentioned in this ticket or would you like a new issue raised?

Same.

public folder mapping has had a small change in vite 5. In aligning dev and preview behaviour vite 5 now returns the index.html file in more cases, so if you're trying to access /locales/en.json which is inside public then you need to get ./locales/en.json instead

rstoneIDBS · 2024-01-03T11:38:25Z

I'm currently experiencing issues with component testing when trying Vite 5.0.7 with Cypress 13.6.1. It looks like 'public' folder mapping is broken which (for me anyway) breaks the use of mock service worker amongst other things. Is this likely to be fixed by the work mentioned in this ticket or would you like a new issue raised?

Same.

public folder mapping has had a small change in vite 5. In aligning dev and preview behaviour vite 5 now returns the index.html file in more cases, so if you're trying to access /locales/en.json which is inside public then you need to get ./locales/en.json instead

Yes, I noticed that in the release notes. I think the code that needs to change is part of the Cypress Vite dev server integration - I couldn't see any way of doing this from the consumer side. My app works fine in Vite dev mode (with Vite 5), it only fails when running Cypress component tests.

SamGeodynamics · 2024-01-03T13:49:56Z

Just tried again with the latest versions of Cypress (13.6.2) and Vite (5.0.10) and I'm still seeing the same issue.

as said; it's not working. (cypress v13.6.2 & vite 5.0.10), you can press skip, then you are greeted with a huge version mismatch notification.

juliandreas · 2024-01-03T14:46:17Z

I think the code that needs to change is part of the Cypress Vite dev server integration - I couldn't see any way of doing this from the consumer side. My app works fine in Vite dev mode (with Vite 5), it only fails when running Cypress component tests.

Same. Imports works fine in the app with Vite 5, but it fails when running Cypress. Changing a path from /locales/en.json to ./locales/en.json, for example, is not helping in that scenario. The Cypress team needs to update their package to support Vite 5.

jennifer-shehane · 2024-02-19T15:07:24Z

We'd be open to a PR to help support Vite 5.

MikeMcC399 · 2024-02-26T14:51:36Z

@jennifer-shehane

We'd be open to a PR to help support Vite 5.

Just for the sake of clarity, since I'm the author of this issue, I'm not able to provide a PR to update Cypress for Vite 5 compatibility. I don't have the skills to do this.

essenmitsosse · 2024-02-29T12:13:51Z

Giving the hefty sums Cypress charges for their service, asking the community to implement support for the latest version of industry-standard tooling, while ignoring the issue for over four month, seems like pretty bad optics. I understand Cypress itself is free and open source, but the lack of Vite 5 support is a road block for Cypress-only users as well as Cypress cloud customers.

waldemarennsaed · 2024-03-25T11:01:48Z

Giving the hefty sums Cypress charges for their service, asking the community to implement support for the latest version of industry-standard tooling, while ignoring the issue for over four month, seems like pretty bad optics. I understand Cypress itself is free and open source, but the lack of Vite 5 support is a road block for Cypress-only users as well as Cypress cloud customers.

I agree on what @essenmitsosse says. Vite 5 is released for a while now. We are currently migrating our whole stack to Vue 3, including Vuetify 3 and the latest Vite version. I do not understand why the Cypress org does not see their responsibility in keeping their tooling up-to-date.

rstoneIDBS · 2024-04-26T08:59:11Z

I've found a fix for the MSW issue :)

I already had a section in my component.js that was configuring the MSW service worker, this also allows you to specify the URL of the worker so I changed it to this:

const { worker, graphql } = await import('../../src/mocks/browser');

Cypress.on('test:before:run:async', () => {
  if (worker.context.isMockingEnabled) {
    return;
  }
  return worker.start({
    serviceWorker: {
      url: '../src/public/mockServiceWorker.js',
    },
    // Disable logging of matched requests as this can occasionally result in test failures
    quiet: true,
  });
});

window.msw = {
  worker,
  graphql,
};

The key bit is the url setting as this ensures that MSW loads its code from the correct location.

This fixes MSW, but it won't fix anything else being served from the 'public' directory so it would be good if Cypress could figure out how to handle this in a more generic fashion.

whitespacecode · 2024-04-29T08:07:35Z

The issue is still present inCypress V13.8.1

rstoneIDBS · 2024-04-29T08:10:19Z

The issue is still present inCypress V13.8.1

See #28347 (comment) - it looks like 13.9.0 might fix this

AtofStryker · 2024-05-08T13:53:44Z

The issue is still present inCypress V13.8.1

See #28347 (comment) - it looks like 13.9.0 might fix this

This did not make it into 13.9.0 since more work needs to be done, but the plan is for me to look back at this in next few days to make sure #28347 (comment) is addressed as well as other possible breaking changes.

AtofStryker · 2024-05-13T15:03:19Z

I've found a fix for the MSW issue :)

I already had a section in my component.js that was configuring the MSW service worker, this also allows you to specify the URL of the worker so I changed it to this:
const { worker, graphql } = await import('../../src/mocks/browser');

Cypress.on('test:before:run:async', () => {
  if (worker.context.isMockingEnabled) {
    return;
  }
  return worker.start({
    serviceWorker: {
      url: '../src/public/mockServiceWorker.js',
    },
    // Disable logging of matched requests as this can occasionally result in test failures
    quiet: true,
  });
});

window.msw = {
  worker,
  graphql,
};
The key bit is the url setting as this ensures that MSW loads its code from the correct location.

This fixes MSW, but it won't fix anything else being served from the 'public' directory so it would be good if Cypress could figure out how to handle this in a more generic fashion.

Glad you found a work around for this @rstoneIDBS .

I'm currently trying to look into the public path issues but I am a bit stuck. The thread above mentions the fallback behavior to index.html and aligning html preview behavior, but the later only applies to html files. I'm struggling to recreate the public path issues at a very basic level since I can see assets still being served from the cypress public path
.

Pardon my ignorance, but what is it that I am missing? Would either you, @juliandreas , or anyone really, be able to help me reproduce the public path issues so I can work on getting this supported?

rstoneIDBS · 2024-05-14T07:56:40Z

In you example above, change line 13 of App.jsx from:
<img src={viteLogo} className="logo" alt="Vite logo" />
to
<img src="/vite.svg" className="logo" alt="Vite logo" />
This will pull the logo directly from the public folder, now if you re-run your Cypress test you will see a broken image where the Vite logo should be. This is simulating the issue I'm seeing with MSW

AtofStryker · 2024-05-14T13:25:31Z

In you example above, change line 13 of App.jsx from: <img src={viteLogo} className="logo" alt="Vite logo" /> to <img src="/vite.svg" className="logo" alt="Vite logo" /> This will pull the logo directly from the public folder, now if you re-run your Cypress test you will see a broken image where the Vite logo should be. This is simulating the issue I'm seeing with MSW

I appreciate the help! I was able to reproduce the problem on my end. Replacing the src with /vite.svg yields the asset can't be found and we need to somehow prefix this with the public path (default /__cypress/src/vite.svg).

rstoneIDBS · 2024-05-14T16:27:45Z

In you example above, change line 13 of App.jsx from: <img src={viteLogo} className="logo" alt="Vite logo" /> to <img src="/vite.svg" className="logo" alt="Vite logo" /> This will pull the logo directly from the public folder, now if you re-run your Cypress test you will see a broken image where the Vite logo should be. This is simulating the issue I'm seeing with MSW

I appreciate the help! I was able to reproduce the problem on my end. Replacing the src with /vite.svg yields the asset can't be found and we need to somehow prefix this with the public path (default /__cypress/src/vite.svg).

I think there might be a way of letting Vite know about additional public directories which I think is what you want to do here - i.e. tell Vite that '/__cypress/src/' is also a public folder. This was where I got to when looking at it before but I couldn't figure out how to configure that part of Vite from the Cypress code that starts the Vite dev server.

Edit: You might need to look at this vitejs/vite#5129

AtofStryker · 2024-05-14T18:53:36Z

In you example above, change line 13 of App.jsx from: <img src={viteLogo} className="logo" alt="Vite logo" /> to <img src="/vite.svg" className="logo" alt="Vite logo" /> This will pull the logo directly from the public folder, now if you re-run your Cypress test you will see a broken image where the Vite logo should be. This is simulating the issue I'm seeing with MSW

I appreciate the help! I was able to reproduce the problem on my end. Replacing the src with /vite.svg yields the asset can't be found and we need to somehow prefix this with the public path (default /__cypress/src/vite.svg).

I think there might be a way of letting Vite know about additional public directories which I think is what you want to do here - i.e. tell Vite that '/__cypress/src/' is also a public folder. This was where I got to when looking at it before but I couldn't figure out how to configure that part of Vite from the Cypress code that starts the Vite dev server.

Edit: You might need to look at this vitejs/vite#5129

I think this actually requires the assets in the specified directories to be on disk. I am wondering if we can accomplish the same thing with a simple proxy?

        proxy: {
          '/': {
            target: `${devServerPublicPathRoute}/`,
            bypass: (
              req,
            ) => {
              // If the request comes from the root folder (i.e. the alias public path in Vite v5)
              // then proxy the assets to the public path for them to resolve correctly as they should.
              if (!req.url?.includes(devServerPublicPathRoute)) {
                const proxyPath = `${devServerPublicPathRoute}${req.url}`

                debug(`Proxying request ${req.url} to public path ${proxyPath}`)

                return `${devServerPublicPathRoute}${req.url}`
              }

              return req.url
            },
          },
        },

Though I would think you might want the ability to turn this off, especially if your server has more complex middleware and is spoofing an api server, so I don't think this is an ideal/perfect solution by any means. We might be able to narrow it down to just assets

AtofStryker · 2024-05-14T20:08:22Z

In you example above, change line 13 of App.jsx from: <img src={viteLogo} className="logo" alt="Vite logo" /> to <img src="/vite.svg" className="logo" alt="Vite logo" /> This will pull the logo directly from the public folder, now if you re-run your Cypress test you will see a broken image where the Vite logo should be. This is simulating the issue I'm seeing with MSW

I appreciate the help! I was able to reproduce the problem on my end. Replacing the src with /vite.svg yields the asset can't be found and we need to somehow prefix this with the public path (default /__cypress/src/vite.svg).

I think there might be a way of letting Vite know about additional public directories which I think is what you want to do here - i.e. tell Vite that '/__cypress/src/' is also a public folder. This was where I got to when looking at it before but I couldn't figure out how to configure that part of Vite from the Cypress code that starts the Vite dev server.
Edit: You might need to look at this vitejs/vite#5129

I think this actually requires the assets in the specified directories to be on disk. I am wondering if we can accomplish the same thing with a simple proxy?
        proxy: {
          '/': {
            target: `${devServerPublicPathRoute}/`,
            bypass: (
              req,
            ) => {
              // If the request comes from the root folder (i.e. the alias public path in Vite v5)
              // then proxy the assets to the public path for them to resolve correctly as they should.
              if (!req.url?.includes(devServerPublicPathRoute)) {
                const proxyPath = `${devServerPublicPathRoute}${req.url}`

                debug(`Proxying request ${req.url} to public path ${proxyPath}`)

                return `${devServerPublicPathRoute}${req.url}`
              }

              return req.url
            },
          },
        },
Though I would think you might want the ability to turn this off, especially if your server has more complex middleware and is spoofing an api server, so I don't think this is an ideal/perfect solution by any means. We might be able to narrow it down to just assets

This is a bit of a smell to me. @rstoneIDBS out of curiousity have you tried setting the devServerPublicPathRoute to root to fix asset resolution, like this:

cypress.config.js

export default defineConfig({
  e2e: {
    setupNodeEvents(on, config) {
      // implement node event listeners here
    },
  },

  component: {
    devServer: {
      framework: "react",
      bundler: "vite",
    },
    devServerPublicPathRoute: '',
  },
});

rstoneIDBS · 2024-05-15T08:23:31Z

@AtofStryker setting devServerPublicPathRoute breaks the test with the following error:

> Failed to resolve module specifier '\cypress\support\component.js'

AtofStryker · 2024-05-15T11:46:13Z

@AtofStryker setting devServerPublicPathRoute breaks the test with the following error:
> Failed to resolve module specifier '\cypress\support\component.js'

@rstoneIDBS I'm struggling to reproduce this error. Are you able to share a reproduction? Also, are you on Windows or running an ESM project?

rstoneIDBS · 2024-05-15T12:40:19Z

@AtofStryker all I did was:

create a new Vite project (npm create vite@latest)
selected React & JavaScript
install and run Cypress
select React + Vite + Component testing.

Modified the App.jsx file as described above and then changed cypress.config to include the devServerPublicPathRoute setting described above - this gave me the described error when running the created Cypress test.

I'm using Windows and the default Vite project is ESM

AtofStryker · 2024-05-15T12:49:26Z

devServerPublicPathRoute: '',

Interesting I did the identical steps and everything works fine. The main difference is that I am not on Windows and am on MacOS 14.3. I bet this is some type of pathing issue specific to Windows. Will try the same steps as well but on Windows.

AtofStryker · 2024-05-15T14:02:07Z

devServerPublicPathRoute: '',
Interesting I did the identical steps and everything works fine. The main difference is that I am not on Windows and am on MacOS 14.3. I bet this is some type of pathing issue specific to Windows. Will try the same steps as well but on Windows.

@rstoneIDBS After investigating it does look like a pathing issue. Hardcoding some values inside @cypress/vite-dev-server gets its going inside windows 37c01ca. Exploring solutions and will keep the thread updated.

AtofStryker · 2024-05-15T20:59:30Z

@rstoneIDBS are you able to try the binary for windows on this commit ac6e96d?

rstoneIDBS · 2024-05-16T07:50:30Z

@rstoneIDBS are you able to try the binary for windows on this commit ac6e96d?

Just tried it with my test case (mentioned above) and with my real code (using MSW) and it appears to be working fine :) Thanks @AtofStryker

I guess the Cypress documentation will be updated to mention this - I can imagine others running into it and the solution (devServerPublicPathRoute) isn't obvious so making this discoverable is going to be a challenge.

AtofStryker · 2024-05-16T12:02:28Z

@rstoneIDBS are you able to try the binary for windows on this commit ac6e96d?

Just tried it with my test case (mentioned above) and with my real code (using MSW) and it appears to be working fine :) Thanks @AtofStryker

@rstoneIDBS glad it works!

I guess the Cypress documentation will be updated to mention this - I can imagine others running into it and the solution (devServerPublicPathRoute) isn't obvious so making this discoverable is going to be a challenge.

This is the tricky part. We don't have a lot of documentation on our bundler dev-servers, but I did add a snippet into the package readme https://github.com/cypress-io/cypress/pull/29518/files#diff-07cdfa8a3a7320f94daa82c1155a2c8de98dc257e0749be5a72dd6789fdfed06R59. Discoverability here is difficult, but it at least gives us something to reference.

cypress-bot · 2024-05-21T20:52:49Z

Released in 13.10.0.

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

This was referenced Nov 17, 2023

Update Vite examples to v5 cypress-io/github-action#1081

Closed

vite.config missing after CT onboarding - unexpected error #26849

Open

haoqunjiang mentioned this issue Nov 21, 2023

[CT] Fix Vite 5 CJS Deprecation Warning and Prepare for Vite 6 #28373

Open

MikeMcC399 mentioned this issue Dec 9, 2023

fix(deps): update all dependencies cypress-io/component-testing-quickstart-apps#15

Merged

jennifer-shehane added type: enhancement Requested enhancement of existing feature CT Issue related to component testing labels Dec 17, 2023

jennifer-shehane added this to Cypress App Priorities Jan 19, 2024

github-project-automation bot moved this to Understanding in Cypress App Priorities Jan 19, 2024

jennifer-shehane removed this from Cypress App Priorities Jan 19, 2024

MikeMcC399 mentioned this issue Jan 20, 2024

CT Supported Frameworks with wildcard "+" version cypress-io/cypress-documentation#5412

Closed

cuixiaorui mentioned this issue Feb 9, 2024

补齐 client 中的单元测试 cuixueshe/earthworm#68

Closed

Rllyyy mentioned this issue Feb 11, 2024

[CODE] Upgrade dependencies Rllyyy/repeatio#378

Closed

3 tasks

rmanaem mentioned this issue Feb 19, 2024

component tests neurobagel/query-tool#20

Closed

1nu1taichi mentioned this issue Mar 8, 2024

dressca の Cypress が実行できない AlesInfiny/maris#743

Closed

mschile assigned AtofStryker May 7, 2024

AtofStryker mentioned this issue May 14, 2024

feat: support vite v5 #29518

Merged

3 tasks

jennifer-shehane added this to Cypress App Priorities May 16, 2024

github-project-automation bot moved this to Understanding in Cypress App Priorities May 16, 2024

jennifer-shehane moved this from Understanding to Building in Cypress App Priorities May 16, 2024

jennifer-shehane mentioned this issue May 16, 2024

Add support of Next.JS 14 #28185

Closed

KentaHizume mentioned this issue May 20, 2024

TypeScript・Viteの設定に関するドキュメントを追加する AlesInfiny/maris#1099

Closed

1 task

AtofStryker closed this as completed in #29518 May 21, 2024

github-project-automation bot moved this from Building to Generally Available in Cypress App Priorities May 21, 2024

cypress-bot bot locked as resolved and limited conversation to collaborators May 21, 2024

jennifer-shehane removed this from Cypress App Priorities Oct 11, 2024

Support vite v5 for component testing #28347

Support vite v5 for component testing #28347

Comments

MikeMcC399 commented Nov 16, 2023

What would you like?

Why is this needed?

Other

MikeMcC399 commented Dec 9, 2023

MikeMcC399 commented Dec 11, 2023

rstoneIDBS commented Dec 11, 2023

juliandreas commented Dec 19, 2023

MikeMcC399 commented Dec 19, 2023

juliandreas commented Dec 19, 2023 • edited Loading

MikeMcC399 commented Dec 19, 2023

rstoneIDBS commented Jan 2, 2024

steveworkman commented Jan 3, 2024

rstoneIDBS commented Jan 3, 2024

SamGeodynamics commented Jan 3, 2024 • edited Loading

juliandreas commented Jan 3, 2024

jennifer-shehane commented Feb 19, 2024

MikeMcC399 commented Feb 26, 2024

essenmitsosse commented Feb 29, 2024

waldemarennsaed commented Mar 25, 2024

rstoneIDBS commented Apr 26, 2024

whitespacecode commented Apr 29, 2024

rstoneIDBS commented Apr 29, 2024

AtofStryker commented May 8, 2024

AtofStryker commented May 13, 2024

rstoneIDBS commented May 14, 2024 • edited Loading

AtofStryker commented May 14, 2024

rstoneIDBS commented May 14, 2024 • edited Loading

AtofStryker commented May 14, 2024

AtofStryker commented May 14, 2024

cypress.config.js

rstoneIDBS commented May 15, 2024

AtofStryker commented May 15, 2024 • edited Loading

rstoneIDBS commented May 15, 2024

AtofStryker commented May 15, 2024

AtofStryker commented May 15, 2024

AtofStryker commented May 15, 2024

rstoneIDBS commented May 16, 2024 • edited Loading

AtofStryker commented May 16, 2024

cypress-bot bot commented May 21, 2024

juliandreas commented Dec 19, 2023 •

edited

Loading

SamGeodynamics commented Jan 3, 2024 •

edited

Loading

rstoneIDBS commented May 14, 2024 •

edited

Loading

rstoneIDBS commented May 14, 2024 •

edited

Loading

AtofStryker commented May 15, 2024 •

edited

Loading

rstoneIDBS commented May 16, 2024 •

edited

Loading