misc: Add generic types to net-stubbing for use in intercept and wait #29508
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds a generic type to the
BaseMessage
interface in net-stubbing, for thebody
property. This then carries over to all of the related request/response types. And importantly into thecy.intercept
andcy.wait
methods, where it will be possible to write generic types for these and have them flow into the callbacks/chainables.Additional details
Why was this change necessary?
See the related issue for examples.
What is affected by this change?
The types that are exported from net-stubbing.d.ts were almost all affected. But their generic types still default to
any
in all cases, so the current behaviour should remain unless the user explicitly writes the generic types.This may be a breaking change, depending on whether current users have specified types on these methods already. I don't think it was possible to write them in this way, but I can't quite figure out if it will be breaking for sure.
Any implementation details to explain?
I'm not sure about the implementation of
cy.wait(['alias1'])
(i.e. the array of aliases). It seems to work, but is slightly tricky to use, because it needs to return an array of both the request and response types for each element in the alias array. As such the user has to specifycy.wait<[[Req1, Res1], [Req2, Res2]]>(['alias1', 'alias2'])
, which is unlike the other overloads. (As an aside, I don't have a current use case for making types on this kind of call, but it made some sense to make it possible).Steps to test
I believe this only affects the experience inside an IDE (I used VSCode). Tested by running the
dtslint
script in thecli
project.I had a slightly hard time with this as I'm on Windows, and couldn't get the project to start. Nor do all the unit tests pass for me locally (but seems like just lots of line endings hopefully?)
How has the user experience changed?
Before (without types) on
intercept
:and after:
Before (without types) on
wait
:and after:
PR Tasks
cypress-documentation
? Not sure if this is required yettype definitions
? These are type definitions in themselves, for another area