misc: Add generic types to net-stubbing for use in intercept and wait

[scottmcginness]

• Closes #29507 This adds a generic type to the BaseMessage interface in net-stubbing, for the body property. This then carries over to all of the related request/response types. And importantly into the cy.intercept and cy.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 specify cy.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 the cli 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

• [x] Have tests been added/updated?
• [ ] Has a PR for user-facing changes been opened in cypress-documentation? Not sure if this is required yet
• [na] Have API changes been updated in the type definitions? These are type definitions in themselves, for another area

[CLAassistant]

All committers have signed the CLA.

[cypress-app-bot]

• Create a Draft Pull Request if your PR is not ready for review. Mark the PR as Ready for Review when you're ready for a Cypress team member to review the PR.

[jennifer-shehane]

@scottmcginness Thanks for the contribution! Can you add a changelog entry for this change? Instructions are here.

[scottmcginness]

Can you add a changelog entry for this change? Instructions are here.

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. The related one seems to be that they are running Webpack with TypeScript 3.9, which did not support the type definitions as written for the cy.wait(string[]) overload. I've reverted how that one works, in favour of just using Interception<any, any> in this case.

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 🤞

[jennifer-shehane]

Rerunning the tests now

[scottmcginness]

a https://github.com/cypress-io/cypress-documentation/pull/5831 to provide examples based on this PR

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.

the changelog will need to be updated

Moved the entry up to the pending section 👍

[cypress-bot[bot]]

Released in 13.11.0.

This comment thread has been locked. If you are still experiencing this issue after upgrading to Cypress v13.11.0, please open a new issue.