There are a handful of code samples around the web (ie. https://github.com/lodash/lodash/issues/1279) that show _.invokeMap being used with _.call to invoke an array of functions:
In these cases, _.call is simply a shorthand for Function.prototype.call.
Unfortunately, babel-plugin-lodash does not like this, and exits with an error if you try to use it:
The 'lodash' method 'call' is not a known module.
While this is a rather perverse use of lodash, it's indeed valid, and I've seen a few uses of it in the wild.
I think it's safe for us to replace any instances of _.call with Function.prototype.call when _.call is part of a MemberExpression (instead of a CallExpression, ie. _.call()), but I'm not sure if there are any cases where that would be incorrect....
Is this something we should bother supporting, or would it be easier to just print a more descriptive warning, and encourage users to eliminate usages of _.call in their code?
This plugin is moving in a lib agnostic direction, to become a generic cherry-pick plugin, so I'd like to avoid support for special edge cases like this.
There are a handful of code samples around the web (ie. https://github.com/lodash/lodash/issues/1279) that show
_.invokeMap
being used with_.call
to invoke an array of functions:In these cases,
_.call
is simply a shorthand forFunction.prototype.call
.Unfortunately, babel-plugin-lodash does not like this, and exits with an error if you try to use it:
While this is a rather perverse use of lodash, it's indeed valid, and I've seen a few uses of it in the wild.
I think it's safe for us to replace any instances of
_.call
withFunction.prototype.call
when_.call
is part of aMemberExpression
(instead of aCallExpression
, ie._.call()
), but I'm not sure if there are any cases where that would be incorrect....Is this something we should bother supporting, or would it be easier to just print a more descriptive warning, and encourage users to eliminate usages of
_.call
in their code?