Can we please overwrite query commands

[bahmutov]

What would you like?

Cypress v12 designated several query commands, and now prevents me from overwriting them. Which broke my plugins bahmutov/cypress-if#58 and bahmutov/cypress-aliases#17
Can we please allow overwriting queries, I promise to use it for good

Cypress.Commands.overwrite('as', ...)

Why is this needed?

I keep track of information or change behavior of several query commands in my plugins

Other

No response

[muratkeremozcan]

cypress-if and cypress-aliases are so core that I wish they were a part of the main code base.

[bahmutov]

and cypress-map :)

[kostiantynvoiku]

With the upgrade to v12 custom commands with Cypress.Commands.overwrite don't work now 😞

[estefafdez]

+1 to solve this issue soon, it's blocking us to be able to update to version 12. Thanks team!

[dpresiana]

+1 to solve this issue soon, it's blocking us to be able to update to version 12. Thanks team!

+1

[salihcem]

+1 to solve this issue soon, it's blocking us to be able to update to version 12. Thanks team!

+1

[BlueWinds]

To everyone responding with "+1" - please use reactions on the issue rather than filling the issue with comments. We are discussing this and thinking about it.

[BlueWinds]

One thing to keep in mind - if we add an API to overwrite queries, it will only be with other queries - there will be no replacing cy.get() with a non-query command. Something like cypress-if will still need to be written differently, rather than the current implementation of overriding .contains() / .get().

My suggestion for cypress-if specifically would be to look at other ways to achieve it that don't involve overwriting particular commands. My suggestion would be to look at either making .if() an assertion directly or having it insert an assertion ahead of itself in the command queue so that verifyUpcomingAssertions will bypass the implicit assertion check. This would also have the benefit of letting it follow any Cypress command, and not just two particular ones that are overridden.

[BlueWinds]

Looking at cypress-aliases, much of it should still work. The exceptions are the overrides of .as and .contains. The .contains override looks like a decent usecase for overriding queries - will definitely take that into consideration.

I don't see that cypress-map needs to override anything? It looks like a very smooth migration to use queries instead of commands.

[sarahTheTester]

What is the motivation for blocking overwrite of queries in the first place? I use query changes similar to Gleb's libraries, but now blocked.

Could it be made configurable by flag?

[emilyrohrbough]

For those that would like to see this feature, can you please add a comment on why overriding a query is needed vs adding a custom query. We are interested in use-cases on why this is desirable beyond it preventing overriding existing queries for the sake of re-using the command name.

[BlueWinds]

What is the motivation for blocking overwrite of queries in the first place? I use query changes similar to Gleb's libraries, but now blocked.

Could it be made configurable by flag?

We didn't block overrwriting so much as not add it - mostly due to time constraints. To support overwriting them will require a new API - Commands.overwrite can't work because queries are implemented differently internally. Even if we'd added a new API out of the box, it still would have required everyone (such as Gleb's plugins) to migrate.

As Emily said, we'd like to see the use cases people have, so when we do create a query overwrite API, we can make sure it's actually useful to people!