Rule for disallowing chaining

[schmod]

Chaining (in any of its forms) is problematic for users seeking to produce an optimized build of lodash.

This plugin should provide a rule that disallows _.chain(), _(), etc.

[ganimomer]

Hi, and thanks for taking the time to open the issue!
I agree with the article about chaining being problematic when trying to optimise for build size.
Although chaining itself has its merits (lazy evaluation and shortcut fusion), ESLint rules should not be opinionated, so I think what we'll do is change the rule prefer-chaining to a more generic rule chaining with always and never options.
This, alongside issue #80, would probably help users who prefer optimising for smaller builds (e.g. for using with webpack).
So this rule is accepted, but will take a bit of time since it requires making the rules work with specific imported functions.

[jfmengels]

[eslint-plugin-lodash-fp]((https://github.com/jfmengels/eslint-plugin-lodash-fp/) is opinionated on this matter, and thus has a no-chain. It's not appropriate if you use vanilla Lodash, but it should be fine until the rule is added here.

I agree with @ganimomer that a prefer-chaining rule would be better for this plugin, though I'm not sure what it should when it is set to something like always. Forbid composition using flow and/or forbid nested Lodash function calls?

[schmod]

Thanks for the quick feedback!

I tend to agree that a general chaining rule could be a good replacement for the existing prefer-chain rule, simply because chaining: always|never is extremely intuitive.

However, the existing prefer-chain rule isn't merely opinionated about the existence of chains -- it's opinionated about avoiding heavily-nested functions, like this abomination: _.map(_.filter(_.sortBy(arr, predicate),exists),toId);

In my case, I would like to be able to forbid nesting and chaining. If we remove prefer-chain, we will likely need to replace it with separate chaining and no-nesting rules.

---

I should also apologize for wording this issue rather directly. When we decide on an approach, I might have some time to take a look at implementing at this in the next few weeks (unless we want to deliberately do #80 first).

[ganimomer]

Hi,
I think this and #80 are really linked - Part of the point of disallowing chaining is using individual functions, and since the plugin doesn't work on individually used functions yet it would make most of the plugin useless. (it only checks for a _ symbol - or a different symbol by configuration)
This is why I added it to a major version milestone - it would take some work making it work, it would probably require some newer ESLint features, and even then it might be slower.

[ganimomer]

So following my previous statement - chaining: always|never sounds intuitive, but if it's set to always, a no-nesting rule would make every nested call a doubly reported line, which isn't what we want.
Why would we want a no-nesting rule that's specific to Lodash methods anyway, if not for chaining? _.flow and its counterparts don't discriminate between Lodash and regular functions.