feat: prefer-immutable-method

[andreineculau]

Would a rule prefer-immutable-method make sense for you? It would barf if there is a non-mutating lodash alternative to the current function e.g. prefer filter over remove.

I could send out a PR if you're in but you want external help.

[ganimomer]

Hey,
Sounds like a good rule overall!
could you give a few examples of code snippets that pass, and a few of code snippets that fail and their error messages?
After that, you're welcome to submit a PR.
Thanks for the contribution!

[andreineculau]

sorry for the delay.

examples based on searching for "mutate" on https://lodash.com/docs

• pull -> without
• pullAll -> difference
• pullAllBy -> differenceBy
• pullAllWith -> differenceWith
• remove -> filter

there are also methods without an alternative method, but obviously with functional alternatives. I personally would still like a warning/error on them, but maybe these should go under a different rule

• fill
• reverse
• assign
• assignIn
• assignInWith
• assignWith
• defaults
• defaultsDeep
• merge
• mergeWith
• set
• setWith
• unset
• update
• updateWith

PS: a 👶 was born, so no time for PR

[ganimomer]

Added in v2.7.0.

[anthochamp]

Good work there but why would it be set as error in recommended rules ? It's not just a "good/bad" stylistic rule, its also about speed/memory consumption as well, am i wrong ?

There's no telling from the original issue or the doc why it isn't a good thing to use mutable. Perhaps its a bad stylistic rule, but its more efficient. I haven't done the test myself but removing one element from 100000 goes faster (and with lot less memory consumption) with mutable than with immutable obviously.

IMHO, it shouldn't be an "error" in recommended rules but a "warning" or not in it, at all.

Anyway lots of our project which are based on ^2.5.0 doesn't pass CI anymore... Just saying.