misc: Add generic types to net-stubbing for use in intercept and wait #29508
Conversation
|
|
|
|
@scottmcginness Thanks for the contribution! Can you add a changelog entry for this change? Instructions are here. |
…s-io#29507) The nested types were apparently not supported (as written) before TypeScript ~4.1.Remove them in favour of just using `Interception<any, any>` in this overload of `wait`.
Thanks for the link! I've added this now, having missed that I should do it the first time around. I noticed now that a few system tests have failed. If someone wants to revive the fully-typed version in future, that's fine by me. It didn't seem easy enough or worth it to get it working in all cases with that extra constraint on the TypeScript version (unless I've missed something). Hopefully those tests will pass now 🤞 |
|
Rerunning the tests now |
There was a problem hiding this comment.
This looks fantastic! Thank you for the comprehensive tests. I've opened a cypress-io/cypress-documentation#5831 to provide examples based on this PR - can you take a look and verify that I'm understanding things correctly?
Unfortunately, we've since released a new version, so the changelog will need to be updated before we can merge it.
This looks just like my use cases, so thank you for this. I've left some comments (hope that's alright!) just on how exactly those work.
Moved the entry up to the pending section 👍 |
|
Released in This comment thread has been locked. If you are still experiencing this issue after upgrading to |
This adds a generic type to the
BaseMessageinterface in net-stubbing, for thebodyproperty. This then carries over to all of the related request/response types. And importantly into thecy.interceptandcy.waitmethods, 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
anyin 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
dtslintscript in thecliproject.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