Return types of Cypress commands

What would you like?

It seems that Cypress.Chainable interface is not really used or required when yielding stuff from one command to another. A visual example:

I’d imagine that in order to use .click() command a previous command needs to return proper type. Ideally compiler should complain about a command chain like this.

Ideally there should be possibility to use this at least with custom commands so that when I create something like cy.createItem() in my codebase, it should be easily identifiable if this returns a response body from API or a DOM element.

@marktnoonan told me I can tag @lmiller1990 on this 😂

Why is this needed?

No response

Other

No response

[lmiller1990]

I wonder if we just need to do a table/doc of all the different combinations that are possible, what we expect, and any edge cases, and re-assess how our types are organized/defined from a more high level… I am not sure how far we can get with incremental improvements. Starting with all DOM node related commands is a good idea. Getting type inference on commands that return DOM elements would be a huge productivity boost.

[filiphric]

I’m thinking maybe a good place to start are commands that we definitely know will return an HTML element, like eq(), .filter(), .parent() etc. and then maybe pair them with all the .should() assertion that only work for DOM elements? It’s not very “rounded feature”, but could maybe work as an initial proof of concept.