(Issue #309) Introduced functional-parameters rules that allows for fp-ts Lazy functions

[Olivex727]

No description provided.

[danielnixon]

We can't rely on this import naming convention. For example, this is from the official fp-ts docs:

import { left, right } from 'fp-ts/Either'
import { tryCatch } from 'fp-ts/TaskEither'

tryCatch(() => Promise.resolve(1), String)().then((result) => {
  assert.deepStrictEqual(result, right(1))
})
tryCatch(() => Promise.reject('error'), String)().then((result) => {
  assert.deepStrictEqual(result, left('error'))
})

You can see that these tryCatch instances wouldn't be picked up by our selector here.

Let's relax this to permit any invocation of any function named tryCatch (or the others). This risks ignoring other, unrelated functions that just happen to have the same name (false negatives) but that's a risk worth taking, at least for now. To do better than that we would need access to the TypeScript type information that isn't present in the plain Esprima AST (which is what these ESLint selectors give us access to).

If possible, let's narrow it down by the number of function arguments too. For example we know that tryCatch takes two arguments, so if possible, let's write our selector in such a way that it won't pick up calls to functions named tryCatch that take more or less arguments than that.

[danielnixon]

Can you think of other functions that are worth adding to this list?

[danielnixon]

🚀

[danielnixon]

eslint-functional/eslint-plugin-functional#575