consistent-tap rule

[leighman]

What is the problem this feature would solve?

Effect.tap allows more that Effect as the return type which is inconsistent with other tap functions.

What is the feature you are proposing to solve the problem?

This rule could either use type information to assert that tap always takes a function that returns an effect or potentially could enforce that uses of tap include an onlyEffect: true option in the arguments (wouldn't require type info?)

What alternatives have you considered?

Encountered this by accidentally providing a (args) => TaskEither<A, E> function to tap. Could just be more careful...