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

breaking: add support for ressources with relative paths #26844

Conversation

fochlac
Copy link
Contributor

@fochlac fochlac commented May 23, 2023

Additional details

Steps to test

create a cypress test that mounts a static ressource via a relative path, i.e. <img src="./path/to/img.png" /> and check whether the request succeds

How has the user experience changed?

It is now possible to distinguish the initial request for the index.html of the CT from relative asset requests (fonts/images/etc). This allows routing those requests to dev-server while retaining the relative paths.
Example: if a component test includes an image defined as follows: <img src="./path/to/img.png" /> the load image request will be forwarded to the url dev-server:port/__cypress/src/path/to/img.png instead of dev-server:port/__cypress/src/index.html.

PR Tasks

@CLAassistant
Copy link

CLAassistant commented May 23, 2023

CLA assistant check
All committers have signed the CLA.

@cypress-app-bot
Copy link
Collaborator

@fochlac fochlac force-pushed the issues-26725-fix-relative-ressource-requests-in-ct branch from d1ea71c to 67b8730 Compare May 23, 2023 21:52
@fochlac fochlac marked this pull request as ready for review May 23, 2023 22:23
@fochlac fochlac marked this pull request as draft May 23, 2023 22:25
@cypress
Copy link

cypress bot commented May 23, 2023

Passing run #47021 ↗︎

0 104 0 0 Flakiness 0

Details:

Merge branch 'develop' into issues-26725-fix-relative-ressource-requests-in-ct
Project: cypress Commit: 8101000f0e
Status: Passed Duration: 16:16 💡
Started: Jun 5, 2023 8:22 AM Ended: Jun 5, 2023 8:38 AM

This comment has been generated by cypress-bot as a result of this project's GitHub integration settings.

@fochlac fochlac force-pushed the issues-26725-fix-relative-ressource-requests-in-ct branch from 4ed7300 to 5e4d02e Compare June 4, 2023 23:36
@fochlac fochlac marked this pull request as ready for review June 4, 2023 23:38
@lmiller1990 lmiller1990 requested a review from a team June 5, 2023 03:36
system-tests/lib/dep-installer/index.ts Show resolved Hide resolved
system-tests/test/webpack_dev_server_spec.ts Outdated Show resolved Hide resolved
@@ -18,7 +18,7 @@ const makeImport = (file: Cypress.Cypress['spec'], filename: string, chunkName:
const magicComments = chunkName ? `/* webpackChunkName: "${chunkName}" */` : ''

return `"${filename}": {
shouldLoad: () => decodeURI(document.location.pathname).includes("${file.absolute}"),
shouldLoad: () => (new URL(document.location)).searchParams.get("specPath") === "${file.absolute}",
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this should be fine, let's see how CI goes.

Copy link
Contributor Author

@fochlac fochlac Jun 5, 2023

Choose a reason for hiding this comment

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

It works, however, this makes it a breaking change I think. This will become a problem if the cypress-version doesn't match the webpack-dev-server version, and I don't know if I can assume this to always be the case.
I considered supporting both variants to be backward compatible, but was not sure if its actually needed.

Copy link
Contributor

Choose a reason for hiding this comment

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

Why is this a breaking change? Can you share some examples of when shouldLoad will be return a different value after your change?

Making a breaking change is definitely not something we take lightly, I think we want to avoid this if possible. Otherwise, this change would need to wait for the next major - a lot of planning goes into these.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If this change would be part of 12.13.1 and some user uses cypress@12.13.1 and @cypress/webpack-dev-server@12.13.0 (or the other way round) no tests would load.

Copy link
Contributor

@lmiller1990 lmiller1990 Jun 6, 2023

Choose a reason for hiding this comment

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

Right, gotcha. Actually this won't be a big problem, but it will be breaking.

We'd wait for Cypress 13, and update this table (from the npm module readme: https://www.npmjs.com/package/@cypress/webpack-dev-server)

image

Let me review and test this a bit more. This will need to be part of v13.

Copy link
Contributor

Choose a reason for hiding this comment

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

I'd missed that document.pathname does NOT include search params. I understand the breaking change now.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I extended the table, should I also update the changelog?

Copy link
Contributor

Choose a reason for hiding this comment

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

The changelog for npm is automated, no problem here.

Copy link
Contributor

@lmiller1990 lmiller1990 left a comment

Choose a reason for hiding this comment

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

This looks pretty good, let me sync with the team on how to get this in v13.

@lmiller1990
Copy link
Contributor

lmiller1990 commented Jun 7, 2023

@fochlac I talked to the team, this will be able to go in Cypress 13. That is at least a month away, so this won't merge for a while, but I'll get some more reviewers on it for you, and we can communicate as Cypress 13 draws closer.

For reference and for other reviewers:

What’s the breaking change that users would experience?

If a user has installed @cypress/webpack-dev-server from npm and configured their own dev-server, then upgraded to a version of Cypress with this change, it would break (the spec would not load).

This workflow (install @cypress/webpack-dev-server manually, instead of using the one that we ship with the binary) is pretty uncommon, it’ll only impact a handful of power users. The change here is an implementation detail. It’s only breaking because the contract between our npm module @cypress/webpack-dev-server and the binary is not guaranteed if you install @cypress/webpack-dev-server on your own instead of the one we include in the binary.

What docs would need to be changed?

Nothing in our main docs, we’d just update this table. This is actually an implementation detail, not part of the public API.

@fochlac
Copy link
Contributor Author

fochlac commented Jun 7, 2023

@lmiller1990 sounds great, waiting for Cypress 13 is no big deal. Thanks for summarizing the breaking changes. I guess I was too deep into the topic to see why it's not obvious. :)

@lmiller1990
Copy link
Contributor

@fochlac thought about this one a bit more - what do you think about keeping the old conditional, and including the new one with an or statement? No breaking change that way - it'll minimize any risk, and we could even release it in a minor/patch.

@fochlac
Copy link
Contributor Author

fochlac commented Jun 7, 2023

@lmiller1990 I thought about this as well, but I think it just covers a less common case.
Let's have a look at the options (considering this is released with 13.0.0):

  1. @cypress/webpack-dev-server@12.13.0 and cypress@13.0.0 -> tests will not load, as the test-path is in the query params and dev-server checks pathname
  2. @cypress/webpack-dev-server@13.0.0 and cypress@12.13.0 -> tests will not load, as test-path is in pathname but webpack checks query params

That change would prevent case 2, however I think that one is the one that is much less likely to occur, that's why I have not left in the alternative check. If you think it's worth it, I'm open to add it though.

@lmiller1990
Copy link
Contributor

lmiller1990 commented Jun 7, 2023

We've got a few weeks to think about it either way. The cleanest way is likely the breaking change as you are pointing out, but glad we considered both angles.

We could potentially add a check in Cypress 13 that looks for an older version of @cypress/webpack-dev-server and throws an error such as "You are on Cypress 13, but using an old version of @cypress/webpack-dev-server. Please update `@cypress/webpack-dev-server`` to version 4".

It would be v4 since the current one is v3: https://www.npmjs.com/package/@cypress/webpack-dev-server - the Cypress major isn't tied to the @cypress/webpack-dev-server version.

Just to clarify, we ship the correct version of @cypress/webpack-dev-server in the binary as part of the cypress package - only users who install @cypress/webpack-dev-server manually (who might want to override the default behavior) will be impacted by this - anyone using the defaults will automatically get updated when they install Cypress 13, so this shouldn't be a problem for the majority of users.

@lmiller1990
Copy link
Contributor

Hey @fochlac, we might want to rebase and retarget this to the v13 branch: #27040

@fochlac fochlac changed the base branch from develop to release/13.0.0 June 21, 2023 19:51
@fochlac fochlac force-pushed the issues-26725-fix-relative-ressource-requests-in-ct branch from 350dafd to 0013774 Compare June 21, 2023 20:10
@fochlac fochlac changed the title fix: support ressources with relative paths breaking: add support for ressources with relative paths Jun 21, 2023
@fochlac
Copy link
Contributor Author

fochlac commented Jun 21, 2023

Thanks for the head's up. I rebased and retargeted the PR. I also adapted the table you mentioned. From your PoV what are the remaining tasks I need to do for this PR?

@lmiller1990
Copy link
Contributor

I don't think any additional work is needed on your end. Let me run CI and see if this is still green.

@lmiller1990
Copy link
Contributor

Cy 13 coming soon. We will get this ready go to.

@@ -68,6 +68,7 @@ We then merge the sourced config with the user's webpack config, and layer on ou
| --------------------------- | ------- |
| <= v1 | <= v9 |
| >= v2 | >= v10 |
| >= v4 | >= v13 |
Copy link
Contributor

Choose a reason for hiding this comment

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

@fochlac hey! We are looking to merge this soon. Should this be v3?

Also can you rebase again? Thank you!

If you can't, let me know and I can try to pick it up.

Copy link
Contributor Author

@fochlac fochlac Aug 8, 2023

Choose a reason for hiding this comment

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

Hi, only saw your comment just now. I think the new version should be v4 as we are currently on v3, and for full compatibility we need dev-server >=v4 and cypress >=v13.
We could consider adapting this like this as well for more clarity:

@cypress/webpack-dev-server cypress
<= v1 <= v9
v2 - v3 v10 - v12
>= v4 >= v13

@lmiller1990 lmiller1990 requested a review from a team July 19, 2023 23:49
@lmiller1990
Copy link
Contributor

I resolved the conflicts, let's get this green and ready to merge.

@lmiller1990
Copy link
Contributor

CI has some issues w/ third party PRs right now. I will try re-opening a new PR with the same commits: #27510

@lmiller1990
Copy link
Contributor

Closing for #27510

Same code but this one cannot pass CI for unknown reasons

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Cypress CT does not support ressources fetched from relative paths
5 participants