Create no-conditional-expect & deprecate no-try-expect

[G-Rath]

Closes #482

I originally was playing around with actually not caring if the expect was in a test, since overall it doesn't really matter where the expect is, it's still best to not have it in a condition, which worked nicely except it would require more logic for handling early returns and early throws.

I think it's doable, but adds more complexity than needed right now, as it started heavily crossing into the territory of other rules like no-test-return-statement.

[G-Rath]

@SimenB I'm wondering if no-if should be renamed to no-conditionals-in-tests, or better yet merged into no-conditional-expect as an option: disallowAnyConditionals.

While the rule name wouldn't quite match the behaviour when the option is enabled, implementation wise it should be a case of just doing option || isExpectCall(node) in the if condition.

[G-Rath]

ESLint 5 is apparently not having a good time in CI:

FAIL lint src/rules/utils.ts
  ● Test suite failed to run

    Failed to load plugin 'eslint-plugin' declared in '../../home/runner/work/eslint-plugin-jest/eslint-plugin-jest/.eslintrc.js': Cannot find module 'eslint-plugin-eslint-plugin'
    Require stack:
    - /tmp/eslint-plugin-jest-jkGeOe/__placeholder__.js
    Referenced from: /home/runner/work/eslint-plugin-jest/eslint-plugin-jest/.eslintrc.js

      at Object.resolve (node_modules/jest-runner-eslint/node_modules/eslint/lib/shared/relative-module-resolver.js:44:50)
          at _normalizeObjectConfigDataBody.next (<anonymous>)
          at _normalizeObjectConfigData.next (<anonymous>)

[G-Rath]

Oh and I'm also thinking we should at some point move the assertFunctionNames option from expect-expect to settings, so that other rules (such as this one) can make use of it.

[github-actions]

🎉 This PR is included in version 23.16.0 🎉

The release is available on:

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

Your semantic-release bot 📦🚀

[janvennemann]

@G-Rath this breaks on of our builds after updating from 23.13.2 to 23.16.0. Not really a big deal since its easily fixable, I was just wondering if it was intended to add a new rule to the recommended configuration that breaks existing setups with a feature update? Shouldn't this be considered a breaking change?

[G-Rath]

@janvennemann yes changing the recommended ruleset is considered a breaking change, which is why this wasn't added to the recommended ruleset.

Would you be able to share your eslint config and more details on your setup, and the errors you got?

[janvennemann]

@G-Rath Duh, for whatever reason we had both all & recommended in our config, so that explains it. As expected removing all solves our issue. Guess i should have taken a closer look before bothering you, sorry ;)