Default ESLint configs about you-dont-need-lodash-underscore HOT 14 CLOSED

Yeah, I can see how people might want to slice "compatibility" different ways:

1. As long as I can swap out the _ function with the native function and know my code won't break, I'm happy. I'm not concerned about sparse arrays because I don't use them (at least not intentionally).
2. I don't consider the native and _ to be compatible unless they behave exactly the same way for all inputs (including edge cases such as sparse arrays).
3. I don't want to swap the _ function with the native function unless I know I have nothing to lose by doing so. If the _ is more efficient (because it doesn't deal with edge cases like sparse arrays), I want to keep it.

Personally, I favor #1. If you and @cht8687 agree, maybe we just run with that. At least for now. We can always come back and add more fields to the JSON file to denote the ramifications of switching from _ to native.

from you-dont-need-lodash-underscore.

For a future smarter version, the linter should error/warn on _.forEach(array) but not _.forEach(object) (at least show a different message) etc.

from you-dont-need-lodash-underscore.

BTW, the settings for the "compatible" flag at the moment may not strictly match any of these definitions. We need to review each rule carefully with respect to whether the native function is truly compatible with the _ function.

On Jul 2, 2016, at 8:47 PM, Steve Mao [email protected] wrote:

rules in which the native implementation exactly matches the _ one

I think this could mean two things:

1. signature of the function is exactly the same but the implementation might be different
2. _ uses the native method

I tend to favour the first definition here for this module.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

from you-dont-need-lodash-underscore.

I've given it some more though and opened #57 and #58. Before we set any default configs, it makes sense to flesh out the options of the individual rules. There's an opportunity to add more nuance than simply which rules are warnings and which are errors.

from you-dont-need-lodash-underscore.

sounds a good idea Pat. @stevemao thoughts?

from you-dont-need-lodash-underscore.

Good idea!

from you-dont-need-lodash-underscore.

Maybe another config to error on rules in which the native implementation exactly matches the _ ones but warn on rules that could be replaced by native?

from you-dont-need-lodash-underscore.

rules in which the native implementation exactly matches the _ one

I think this could mean two things:

1. signature of the function is exactly the same but the implementation might be different
2. _ uses the native method

I tend to favour the first definition here for this module.

from you-dont-need-lodash-underscore.

Yes, if I understand correctly, that's what I would probably want as a default. Error if I know I can replace the _ function with a native function that works the same way. Warn if I may or may be able to switch to native depending on the use case.

That's the config I called safe-strict. I'm not crazy about that particular name. If we put our heads together I bet we can come up a useful set of config options and a more intuitive naming scheme.

On Jul 2, 2016, at 8:28 PM, Steve Mao [email protected] wrote:

Maybe another config to error on rules in which the native implementation exactly matches the _ ones but warn on rules that could be replaced by native?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

from you-dont-need-lodash-underscore.

I would say if the contracts match. For any given input the _ and native functions will produce the same output. I think that's what you meant by signature but want to be sure.

On Jul 2, 2016, at 8:47 PM, Steve Mao [email protected] wrote:

rules in which the native implementation exactly matches the _ one

I think this could mean two things:

1. signature of the function is exactly the same but the implementation might be different
2. _ uses the native method

I tend to favour the first definition here for this module.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

from you-dont-need-lodash-underscore.

signature I mean the type of the parameters and return value are exactly the same. And it does exactly the same thing as the native method. The internal implementation/performance might be different.
A lot of array methods are not. EG: because _ uses a stripped-down version of loop so it gains performance but doesn't work with sparse arrays.

from you-dont-need-lodash-underscore.

That's the config I called safe-strict.

Sorry yes, I misread your comment.

from you-dont-need-lodash-underscore.

Would love to have an all that defaults to error and any reasonable default config. This is similar to eslint:all and plugin:react/all. I'm happy to selectively disable or configure things myself.

from you-dont-need-lodash-underscore.

Really good idea, I just found out about this repo and I was wondering how to setup all rules to errors in a simple way.

from you-dont-need-lodash-underscore.