cy.log now returns null in v10.5, used to be undefined

Current behavior

cy.log used to return undefined, so it could be inserted into the command chain without changing the subject

...
  .then(cy.log)
  ...

Now cy.log returns null, changing the subject

Desired behavior

cy.log should still return undefined

Test code to reproduce

Repo and branch https://github.com/bahmutov/cypress-test-tiny/tree/cy-log-bug

describe('cy.log', () => {
  it('works', () => {
    cy.wrap(42).should('equal', 42)
  })

  it('does not work', () => {
    // not working in Cypress v10.6.0
    // not working in v10.5.0
    // worked in v10.4.0
    // fails with "null" not equal 42
    cy.wrap(42).then(cy.log).should('equal', 42)
  })
})

Cypress Version

10.5.0

Node version

16

Operating System

mac

Debug Logs

No response

Other

No response

[bahmutov]

Ughh, the change makes no sense. Sure, the docs could be saying (an incorrect) thing for 6 years, yet it was not an issue and allowed to quickly print a value inside a long chain. The advice to close the chain with cy.log does not really help.

The solution is to write a big callback and wrap the value - no, just no. Instead, I would suggest

• returning undefined from cy.log. I don’t see any reason to change the subject in cy.log, we already have plenty of problems with should('have.attr') and similar assertions that do unexpectedly change the subject
• extend cy.log to intelligently stringify an object when passed in (so it does not collapse it into [object Object])

just my two million cents

[mike-plummer]

@bahmutov The conclusion we’ve come to internally is that this was not an intentional change, and it is just a coincidence that the behavior actually now matches our documentation. So, this isn’t strictly a bug but rather a feature request to change the documented behavior back to the previous implementation. That said, it’s a good one - the use case you’ve lined out feels very useful. We’ll send this on to the team to do analysis and prioritize

(internal convo ref)