-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
breaking: add support for ressources with relative paths #26844
Conversation
|
d1ea71c
to
67b8730
Compare
Passing run #47021 ↗︎
Details:
This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. |
4ed7300
to
5e4d02e
Compare
@@ -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}", |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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)
Let me review and test this a bit more. This will need to be part of v13.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this 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.
@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 This workflow (install 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. |
@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. :) |
@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. |
@lmiller1990 I thought about this as well, but I think it just covers a less common case.
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. |
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 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 Just to clarify, we ship the correct version of |
350dafd
to
0013774
Compare
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? |
I don't think any additional work is needed on your end. Let me run CI and see if this is still green. |
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 | |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 |
I resolved the conflicts, let's get this green and ready to merge. |
CI has some issues w/ third party PRs right now. I will try re-opening a new PR with the same commits: #27510 |
Closing for #27510 Same code but this one cannot pass CI for unknown reasons |
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 succedsHow 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 urldev-server:port/__cypress/src/path/to/img.png
instead ofdev-server:port/__cypress/src/index.html
.PR Tasks
cypress-documentation
?type definitions
?