become the defacto functional-programming eslint plugin.

[graingert]

• deprecate eslint-plugin-better @idmitriev
• deprecate eslint-preset-cleanjs @bodil
• rename eslint-plugin-cleanjs to eslint-plugin-fp ? @jfmengels

[graingert]

@idmitriev I've noticed you've accepted my invite to eslint-plugin-cleanjs, what are your thoughts on moving eslint-plugin-better over to eslint-plugin-cleanjs ?

[nickmccurdy]

That looks promising, but there are a lot of rules and I'm not sure how it brings these projects together (though it seems to be a fork of eslint-plugin-better that includes sources from some other projects). Could you please document where different parts of the project are coming from and/or add a table of rule origins? While I agree with simplifying overlap between common packages, they already have some traction, and it may be better to keep some of them separate but have them as dependencies of one config. Also I personally prefer the eslint-plugin-fp name, it's a bit more semantically meaningful of the goal of the rule set.

[graingert]

That looks promising, but there are a lot of rules and I'm not sure how it brings these projects together (though it seems to be a fork of eslint-plugin-better that includes sources from some other projects).

It's actually a fork of eslint-plugin-fp, you can see the rules imported from eslint-plugin-better: 64fb977

While I agree with simplifying overlap between common packages, they already have some traction, and it may be better to keep some of them separate but have them as dependencies of one config.

I disagree, it would be better to have one fp config and ruleset with a big active team behind it.

Also I personally prefer the eslint-plugin-fp name, it's a bit more semantically meaningful of the goal of the rule set.

I do too. I just need @jfmengels to agree to merge with this project.

[nickmccurdy]

I see, how about we turn the list of rules into a table showing the origin of each rule?

I appreciate the idea of simplifying these packages into one, but it's more likely that one or two packages would be merged than all of them IMO. Duplicating code from another project that does not want to merge would create maintenance burden for both projects, and could cause difficult merge conflicts. I would prefer to have this package depend on those packages and provide one config as a convenience, not copying any code except from projects that are confirmed to be transitioning.

Here's a relevant xkcd comment:

[graingert]

@nickmccurdy you can just use eslint-preset-cleanjs for that.

[nickmccurdy]

Either way, I think it would be easier to make the transition gradually from the bottom up (by merging individual projects one by one). I may make a PR to fix idmitriev/eslint-plugin-better#4, but I will continue to watch this project. Thanks.

[nickmccurdy]

@graingert I'm sorry, I totally forgot about jfmengels/eslint-plugin-fp#32, I'll take a look at it.