eslint-plugin-promise
eslint-plugin-promise copied to clipboard
'promise/catch-or-return' matches incorrectly with Cypress
Description
When using the rule promise/catch-or-return you get a error with Cypress because they have a then method.
https://docs.cypress.io/api/commands/then.html#Syntax
Steps to Reproduce
- Create repo with this module and Cypress installed
- Create integration file where you make use of
thenmethod. (see docs)
Expected behavior: Need a way to exclude this since this isn't actually a promise.
Actual behavior:
This line is marked as needing a catch added but this isn't a promise.
Versions
- Node version: v10.16.2
- ESLint version: v5.3.0
- eslint-plugin-promise version: v4.2.1
Additional Information
Not sure why the library thinks this is a promise but it shouldn't.
+1, I got the same trouble, so I manually add specific exceptions to overrides block
-
The reason it gets confused is because eslint doesn't run the code or have any idea on the actual types, it has to use heuristics to guess and the best one to use is if there's a method called
.then() -
The Cypress docs say
.then() is modeled identically to the way Promises work in JavaScript. -
Eslint already provides a way to disable a rule per file using
/* eslint-disable promise/catch-or-return*/ -
You can also disable per-folder (such as your testing folder) with a custom
eslintrc.jsfile
That all being said....is the parent variable always called something like cy. If that's the case it would be possible to exclude it.
AFAIK and according to the docs, there's always the top-level global variable named cy in Cypress method chaining
The promise/always-return is also incorrectly matched. I added rules overrides in my eslint config to disable them just for Cypress, e.g.:
"overrides": [
{
"extends": ["plugin:cypress/recommended"],
"files": ["cypress.config.ts", "cypress/**/*.ts"],
"parserOptions": {
"project": ["cypress/tsconfig.json"]
},
"rules": {
"promise/always-return": "off",
"promise/catch-or-return": "off"
}
},
The same problem occurs if prefer-await-to-then is enabled. Detecting cy would be a good heuristic, but not fully reliable if one is using utilities to call cy. Still, might be helpful to avoid the need for overrides.