Don't allow assigning return values to objects

[jeremy-ebler-vineti]

I have a team that's started writing Cypress like:

context('Foo', () => {
  const scope = {}
  it('allows this', () => {
    scope.baddie = cy.get('it')
  })
  ...
})

I was expecting no-assigning-return-values to error out on the assignment of a cypress command to scope.baddie.

const scope = {} is also discouraged by Cypress's Docs, but that's another issue.

[brettz9]

For whoever might work on implementing this change, there are plenty of other contexts where a return value gets used, e.g., within a template, as part of a binary expression, etc. etc.

In our work on eslint-plugin-unicorn, we found that rather than trying to blacklist the various other contexts where the return value might be used besides variable declarations (discussed more fully at sindresorhus/eslint-plugin-unicorn#503 ), that a simple utility could be used to whitelist only those cases where the return values are known not to be used, i.e.:

module.exports = ({parent}) => !parent || parent.type === 'ExpressionStatement';

Then just call this method with the node in question, e.g., isValueNotUsable(node) to see whether this is safe (and an error can be reported otherwise).

You may need to expand though to check the ancestor chain to allow for chained commands like cy.abc().def() since you don't want those to be allowed.

[brettz9]

By the way, this proposed expanding to other contexts could help catch another problem, namely that Cypress doesn't seem to like await to be used (though I wonder whether this can be liberalized to be permitted where a Promise is explicitly allowed, i.e., with cy.task).

[brettz9]

Or if cypress-io/cypress#6575 is implemented, to liberalize returning a (Promise) value from a known custom command.

[MikeMcC399]

• Namespace for custom commands cypress#6575 was closed as not planned