Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: vite v3 not working with node >=17 #23048

Merged
merged 7 commits into from Aug 2, 2022
Merged

Conversation

ZachJW34
Copy link
Contributor

@ZachJW34 ZachJW34 commented Aug 1, 2022

User facing changelog

CT projects using Vite v3 work with Node versions >=17, and a comma is removed from react + vite 3 apps in index.html

Additional details

We now force the host to be 127.0.0.1 when spinning up the vite-dev-server. We did the same fix for webpack a while ago (#21430) and Vite v3 needs a similar fix.

I also fixed an issue that is only prevalent when using vite + react where a comma was being inserted into the served index.html due to how we were injecting scripts.

I added a vite setup for the simple-ct system test proejct and added it to the binary tests to verify behavior across node versions.

Steps to test

This issue can be seen inside our own codebase, just switch to a node version >= 17 and try running any our our vite component tests. See the original issue for repro steps, you can now point the locally running cypress at a vite 3 project using a node version >= 17 and it will now work.

How has the user experience changed?

Before: (Notice the comma on the second load when I switch back to Node 16)

Screen.Recording.2022-08-01.at.3.55.48.PM.mov

After:

Screen.Recording.2022-08-01.at.3.57.04.PM.mov

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)
  • [na] Has a PR for user-facing changes been opened in cypress-documentation?
  • [na] Have API changes been updated in the type definitions?

@ZachJW34 ZachJW34 requested review from a team as code owners August 1, 2022 21:01
@cypress-bot
Copy link
Contributor

cypress-bot bot commented Aug 1, 2022

Thanks for taking the time to open a PR!

@cypress
Copy link

cypress bot commented Aug 1, 2022



Test summary

37827 1 473 0Flakiness 11


Run details

Project cypress
Status Failed
Commit 1ead548
Started Aug 2, 2022 9:57 PM
Ended Aug 2, 2022 10:14 PM
Duration 16:56 💡
OS Linux Debian - 11.3
Browser Multiple

View run in Cypress Dashboard ➡️


Failures

cypress/e2e/commands/net_stubbing.cy.ts Failed
1 ... > when body contains ascii

Flakiness

cypress/e2e/commands/xhr.cy.js Flakiness
1 ... > logs request + response headers
2 ... > logs Method, Status, URL, and XHR
3 ... > logs response
4 ... > logs request + response headers
5 ... > logs Method, Status, URL, and XHR
This comment includes only the first 5 flaky tests. See all 11 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

Copy link
Contributor

@astone123 astone123 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tested this by running some CT tests in the app package. Those wouldn't run before this change when using Node 18 and now they do.

Thanks 🎉

@ZachJW34
Copy link
Contributor Author

ZachJW34 commented Aug 1, 2022

Binary tests I added aren't too happy ☹️

@lmiller1990
Copy link
Contributor

Vite was working on Node.js 17 just fine, in my case.

I wonder if it's either

  1. only Node.js 18+ with the problem
  2. linux vs macos difference?

@@ -76,7 +76,7 @@ export const Cypress = (
indexHtmlContent = indexHtmlContent.replace(
'<head>',
`<head>
${scriptTagsToInject.map((script) => script.toString())}
${scriptTagsToInject.map((script) => script.toString()).join('')}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this essential or just nice to have? Just curious
Right... "and a comma is removed from react + vite 3 apps in index.html". Argh lol... but since this is in <head> it shouldn't actually render anything, which is good - Percy would've picked this up.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Check out the before video (near the end), it was actually rendering a comma that was visible. I don't think Percy would have caught this since we don't snapshot our system tests. Going to look into this a bit more, since like you said I shouldn't have seen the comma if it was in the <head> so somehow it's making it's way to the body

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After digging into this, I discovered that if we insert text into the head that doesn't parse correctly (in this case, we had the comma due to the stringified array), it will get shifted into the body.
Before:
Screen Shot 2022-08-02 at 12 13 04 PM

After:
Screen Shot 2022-08-02 at 12 12 25 PM

So this fix is more important that I thought.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do browsers do things like "move text from <head> into <body>???? 👎

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does not seem to impact percy what-so-ever though! Weird.

@@ -76,7 +76,7 @@ export const Cypress = (
indexHtmlContent = indexHtmlContent.replace(
'<head>',
`<head>
${scriptTagsToInject.map((script) => script.toString())}
${scriptTagsToInject.map((script) => script.toString()).join('')}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the toString still necessary here since join should call toString on the contents?

Suggested change
${scriptTagsToInject.map((script) => script.toString()).join('')}
${scriptTagsToInject.join('')}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's clean I'll throw this in

@lmiller1990 lmiller1990 self-requested a review August 2, 2022 22:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants