Cypress 12 Compatibility

[elylucas]

Greetings from the @cypress-io team. Cypress 12 is coming out next week, and some changes might affect your plugin. One of the big changes is introducing a new API to register custom commands, which helps fix one of the oldest and most annoying issues with Cypress, the “Detached DOM” error.

For commands that are classified as queries (mainly used to return something like a DOM element), there is a new Cypress.Commands.addQuery method. The addQuery method greatly simplifies writing custom query commands and has the benefit of not encountering detached DOM errors.

If your plugin currently registers custom command “queries”, we recommend updating your plugin to use the new API for Cypress 12. Note the API is only going to be in Cypress 12 and newer.

To test out a prerelease version of Cypress 12, you can follow the instructions for installing a prerelease binary here, but instead of using the develop branch use the release/12.0.0 branch.

We recommend all plugin authors test their plugins against the Cypress 12 prerelease to check for compatibility.

If you have any questions, contact us by pinging me on this issue or in our Discord server.

You might find our Retry-ability Guide (updated to cover the latest changes), and Cypress 12 Migration Guide | Cypress Documentation helpful as well.

Thanks

[bahmutov]

.then(parseFloat) for example could be considered a query. Would be nice to have an option to mark cy.then safe to retrySent from my iPhoneOn Nov 28, 2022, at 18:25, Ely Lucas ***@***.***> wrote: Greetings from the @cypress-io team. Cypress 12 is coming out next week, and some changes might affect your plugin. One of the big changes is introducing a new API to register custom commands, which helps fix one of the oldest and most annoying issues with Cypress, the “Detached DOM” error. For commands that are classified as queries (mainly used to return something like a DOM element), there is a new Cypress.Commands.addQuery method. The addQuery method greatly simplifies writing custom query commands and has the benefit of not encountering detached DOM errors. If your plugin currently registers custom command “queries”, we recommend updating your plugin to use the new API for Cypress 12. Note the API is only going to be in Cypress 12 and newer. To test out a prerelease version of Cypress 12, you can follow the instructions for installing a prerelease binary here, but instead of using the develop branch use the release/12.0.0 branch. We recommend all plugin authors test their plugins against the Cypress 12 prerelease to check for compatibility. If you have any questions, contact us by pinging me on this issue or in our Discord server. You might find our Retry-ability Guide (updated to cover the latest changes), and Cypress 12 Migration Guide | Cypress Documentation helpful as well. Thanks —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[BlueWinds]

Hey Gleb - I agree that the ability to quickly do things like parseInt is a good idea, and it's been on my mind as a good quick follow-up for 12.1 or 12.2.

I'd prefer to take the approach of a new command, rather than overloading .then() further. I've been struggling to come up with a good name, if you have any thoughts.

• .query()? This would align with "queries are a type of command", and the best I've come up with so far.
  • cy.get('input').invoke('val').query(parseInt).should('equal', 10) reads pretty naturally.
• .call() - Another naming option for an entirely new command.
  • cy.get('input').invoke('val').call(parseInt).should('equal', 10)
• Add another signature to .invoke() - it'd look like '.invoke(fnOrString, arg1, arg1, ...)`. If a string, we call a method on the subject, and if a function, we call it with the subject as the first arg.
  • cy.get('input').invoke('val').invoke(parseInt).should('equal', 10) also isn't bad.

[bahmutov]

This is what I would do: add a cy.map query command that would be take a pure or async pure function (yeah, I know, but still) and re-query it when needed

cy.get('li')
  .map('innerText') // or some kind of mechanism to access the props and values
  .map(parseInt)
  .should('deep.equal', [...])

I think the same could work for pure methods as well - if the argument is a string, and it is a method's name on the current subject, it should invoke it (and assume the subject does not change)

cy.get('li')
  .map('text')
  .should('equal', ...)

[BlueWinds]

Accepting a string argument and either accessing the value or calling that function are .its() and .invoke(), so we already have these. Overloading .invoke() so that it accepts a function as well as a string is definitely an option I'm considering.

.map() is a super good name though, better than the ones I'd come up with. 👍

[bahmutov]

yeah, all to make it simple to understand, just the question is of handling collections vs individual objects I think

[khitrenovich]

I might be late to the party, but I'm afraid map will be confusing - see Array or Lodash methods.

[bahmutov]

I don't think so. This is specifically recreates the same behavior and is intended to. Or have any side effects (like array map but not array forEach)

[bahmutov]

Ok, this module works with Cypress v12, for extra queries see https://github.com/bahmutov/cypress-map