fix: Cannot add commands with "reserved" names

[davidmunechika]

• Closes Cannot add commands with "reserved" names: getAlias, reset #6146

User facing changelog

Attempting to add a new command using Cypress.Commands.add() that has the same name as an internal function reserved by Cypress will show an improved error message explaining why the command name must be changed.

Additional details

Previously users would encounter strange behavior when trying to add new custom commands with the same name as a reserved internal function by Cypress (i.e. TypeError...). This change improves the error message to explain that users cannot name new custom commands as the same name as an internal function already reserved by Cypress.

Old behavior:

New error and stacktrace:

PR Tasks

• Have tests been added/updated?
• Has the original issue or this PR been tagged with a release in ZenHub?
• Has a PR for user-facing changes been opened in cypress-documentation? Adding an existing command or reserved internal function with Cypress.Commands.add() will throw an error cypress-documentation#4178

[cypress-bot]

Thanks for taking the time to open a PR!

• 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.
• Become familiar with the Code Review Checklist for guidelines on coding standards and what needs to be done before a PR can be merged.

[cypress]

---

Test summary

18149 • 0 • 202 • 0 • 1

---

Run details

Project	cypress
Status	Passed
Commit	5502541
Started	Dec 2, 2021 2:18 PM
Ended	Dec 2, 2021 2:30 PM
Duration	11:54 💡
OS	Linux Debian - 10.10
Browser	Multiple

View run in Cypress Dashboard ➡️

---

Flakiness

	cypress/integration/cypress/proxy-logging-spec.ts		1
1	Proxy Logging > request logging > xhr log has response body/status code

---

This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard

[emilyrohrbough]

@davidmunechika Do you have a screenshot of the new error & stack trace?

[davidmunechika]

@emilyrohrbough

[chrisbreiding]

Here's a way to reproduce an issue with cy.reset:

Cypress.Commands.add('reset', () => {})

it('a test', () => {})

It errors even though the user hasn't called the cy.reset() command they created, because we use it internally.

We need to do this for every method/property we add internally to cy. If they "add" a command with that name, it's overriding the functionality of that method and can cause issues. It might take a certain set of circumstances to reproduce an issue, but those methods are relied on somewhere in the codebase, so we can't allow them to be overwritten.

Really, we shouldn't have so many utility methods attached to cy. I think most of them are on there for convenience's sake. I would say we shouldn't have any undocumented methods on cy. At least they should be prefixed with an underscore or under a namespace that makes it clear they're for internal use. Something that reduces the number of unusable command names. Even better would be to refactor them out into more appropriate places and reduce the need for a massive object of utility methods. But this should be a separate discussion and effort.

For now and for this PR, I think it makes sense to add all these methods/properties to the list of reserved names and error if a user tries to use them. In the current state of the world, they'll cause unexpected behavior if overridden. Then if we refactor them off of cy in the future, they can be removed from the list of reserved names.

The base branch was changed.

[chrisbreiding]

I changed the base branch to 10.0-release, but I'm sure how well that will resolve. It's possible it would be easier to create a new branch based off 10.0-release and cherry-pick the changes into it.

[CLAassistant]

All committers have signed the CLA.