feat: _addQuery()

[BlueWinds]

• Closes https://github.com/cypress-io/cypress/issues/23550

User facing changelog

This PR contains three user-facing changes:

• The addition of Cypress.Commands.addSelector(), in packages/driver/src/cypress/commands.ts and packages/driver/src/cypress/command_queue.ts. This currently an internal API - it will be added to the documentation and finalized as part of upcoming work.
• Migrating .get() to be the first selector.
• Moving Aliases to use concept of "subject chains" rather than re-running commands via the command queue, in packages/driver/src/cy/commands/querying/querying.ts and packages/driver/src/cy/commands/aliasing.ts.

Additional details

TODO

Steps to test

TODO

How has the user experience changed?

.get() should no longer be susceptible to Detached DOM errors. I intend to write additional tests around it, but please note the one I had to delete in within.cy.ts - it no longer fails, because addSelector() isn't susceptbile to that issue!

PR Tasks

• [x] Have tests been added/updated? Some have been added, but I would like to add more before merging, especially around custom commands and selectors.
• [ ] Has the original issue (or this PR, if no issue exists) been tagged with a release in ZenHub? (user-facing changes only)
• [ ] Has a PR for user-facing changes been opened in cypress-documentation?
• [ ] Have API changes been updated in the type definitions?

[cypress-bot[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[bot]]

---

Test summary

41100 • 0 • 3396 • 0 • 4

---

Run details

Project	cypress
Status	Passed
Commit	9263b69439
Started	Sep 28, 2022 3:39 PM
Ended	Sep 28, 2022 3:55 PM
Duration	16:55 💡
OS	Linux Debian - 11.3
Browser	Multiple

View run in Cypress Dashboard ➡️

---

Flakiness

	runs.cy.ts		1
1	App: Runs > Runs - Create Project > when a project is created, injects new projectId into the config file, and sends expected UTM params
	specs_list_latest_runs.cy.ts		1
1	App/Cloud Integration - Latest runs and Average duration > when no runs are recorded > shows placeholders for all visible specs
	e2e/origin/config_env.cy.ts		1
1	cy.origin- Cypress.config() > serializable > overwrites different values in secondary, even if the Cypress.config() value does not exist in the primary
	next.cy.ts		1
1	Working with next-12.1.6 > should show compilation errors on src changes

---

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

[mikelhamer]

So hype for this fix!!! Keep up the great work :)

[BlueWinds]

Spent a bit of time profiling this change. I tried several different tests, but ultimately settled on this one, executed in open mode:

it('should go fast', () => {
  // packages/driver/cypress/fixtures/dom.html
  cy.visit('/fixtures/dom.html')

  for (let i = 0; i < 500; i++) {
    cy.get('#button').as('a' + i)
  }
  for (let i = 0; i < 500; i++) {
    cy.get('@a' + i).should('exist')
  }
})

This results in a huge number of log messages, DOM snapshots, and command executions. I ran this test in Firefox and recorded the time from the runner, and memory usage from the Firefox web process 15s after the test had ended (when FF had time to run several garbage collection cycles).

develop branch:

• 68s, 1021mb
• 70s, 1400mb
• 74s, 1600mb

issue-7306-addSelector-redux branch:

• 67s, 840mb
• 69s, 1200mb
• 70s, 1600mb

The execution times and memory usage are comparable; At the very least this branch isn't slowing anything down significantly; it might be speeding things up slightly, but the difference is small enough it could be luck.

Note the climbing memory usage across runs - I'm pretty sure we have a memory leak between tests, and this is something I want to look into - but it's preexisting, not introduced by this PR.

I also ran this test with most logs disabled:

  it('should go fast', () => {
    cy.visit('/fixtures/dom.html')
    for (let i = 0; i < 500; i++) {
      cy.get('#button', {log: false}).as('a' + i)
    }
    for (let i = 0; i < 500; i++) {
      cy.get('@a' + i, {log: false}).should('exist')
    }
  })

In this case, runs were consistently 9s regardless of branch, and memory usage went roughly 500 -> 550 -> 600mb. This test does suggest that our logs are extremely resource intensive, which is something else I want to look into, unrelated to the detached DOM work.

[BlueWinds]

Also went and ran this test in run mode, and the results are consistent.

develop:

• 96491ms
• 95579ms

issue-7306-addSelector-redux:

• 94935ms
• 94621ms

Having done this several times in a couple of different ways, I'm now confident that .get() as a query is faster. Only by a small margin, but it's consistently faster across runs and modes.

[BlueWinds]

I've pushed some additional changes to this branch since the last review, merging in develop and fixing some subsequent merge conflicts and test failures.

Re-requesting review from those who've approved, and thank you for your patience while I got this into shape again!

[BlueWinds]

Currently failing tests are flake; cypress-schematic will be fixed in develop soon (thanks Ryan!), and the driver-integration-tests-electron-experimentalSessionAndOrigin is known flake from cy.origin + cy.go().