Handle ImportBindings in no-unnecessary-waiting rule

[walaszczykm]

This PR adds proper handling for ImportBindings in no-unnecessary-waiting rule to prevent reporting codes like this:

// We don't know if WAIT is a number or alias '@someRequest'
import { WAIT } from './constnats'

cy.wait(WAIT)

It's similar to the existing case with function arguments where we cannot see the type of the argument. Similarly, we cannot know the type of import binding.

  // function wait (amount) { cy.wait(amount) }
  // we can't know the type of value, so don't fail
  if (!param || param.type !== 'AssignmentPattern') return false

Resolves #43

[spencer-vizio]

@walaszczykm Any update if this can get merged? I deal with this constantly :(

[walaszczykm]

@spencer-vizio I would love to! 🙌 Unfortunately, I am not a core contributor to this project, and it looks like the conversation on the issue lost track after my comment and PR submission 😢

[klarzynskik]

Hey @nagash77 or @chrisbreiding, maybe you would be able to help with merging this or advise? 🙏🏼 Apologies for the direct mention, but this one seems ready to go. 🤞🏼

[CLAassistant]

All committers have signed the CLA.

[emilyrohrbough]

@walaszczykm can you please sign the CLA?

[walaszczykm]

@emilyrohrbough Sure signed! ✅ thanks for taking a look at this 🙂

[emilyrohrbough]

@walaszczykm I am reading this change, and I am not sure this is a valid change to this rule. This eslint rule was written to error/warn when unnecessary waits for specific hard-coded number is sued and this change would allow this to "passed" when really this isn't always necessary.

Is this removing the validity of the rule or is this change just accounting for/correctly linked values that are imported?

[walaszczykm]

@emilyrohrbough

This eslint rule was written to error/warn when unnecessary waits for specific hard-coded number is sued and this change would allow this to "passed" when really this isn't always necessary.

I am mainly referring to this existing condition in the rule's code:

  // function wait (amount) { cy.wait(amount) }
  // we can't know the type of value, so don't fail
  if (!param || param.type !== 'AssignmentPattern') return false

If we can not be sure about the type of value IMO the rule shouldn't try to force it as a bad practice and simply make it don't fail. This is exactly the same case with import bindings like it is with function augments that don't have default values. I can add a similar reasoning argument as a code comment near added line so it would be more clear.

I have rerun the test, and yes, the example in the PR is properly reported so I will rewrite the PR description to don't make confusion and refer to the case with function arguments plus add a code comment 👍

[mschile]

Thanks for the contribution @walaszczykm and sorry for the delay in getting this PR merged!

[nagash77]

🎉 This PR is included in version 2.13.3 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀