[Rule proposal] Limit usage of promise API to current ECMA standard about eslint-plugin-promise HOT 6 OPEN

I don't think I agree with this, because then the rule becomes less helpful to many people. Is there a specific case where it's handling bluebird (or other style) promises incorrectly?

from eslint-plugin-promise.

The problem is not incorrect handling but rather more than the standard.
There is a big benefit (advantage) to stick to the standard in order to avoid "locking" to a specific library. Otherwise, when you want to switch to different promises library (common situation) it becomes very problematic.
I understand the argument that the rule becomes less helpful to many people; for sure if you are not considering long-term development. So, the rule can be provided as default with "off" or "warn".

from eslint-plugin-promise.

@tamirmen, @lidortal I think I misunderstood the proposal. Your suggestion here is a rule that might look like this:

"promise/spec-only": "error"

Which would effectively ban you from doing any of the non-spec stuff like p.done() or Promise.try?

I think I'm okay with this idea, could you put together a proposal of what exactly should result in an error?

from eslint-plugin-promise.

Yes, this is the idea.

IMO when someone uses non-spec stuff, an error should be returned with the message - follow the standard.
For example:
prom.then() - wouldn't return an error.
prom.spread() - would return an error.

from eslint-plugin-promise.

@xjamundx - is there any progress on this topic?

from eslint-plugin-promise.

#72 is related to this issue and has some useful test cases and implementation suggestions that would help in resolving this feature request.

Help is wanted with a PR, but I will try to open a PR in the next week or so. Please communicate if you would like to contribute this feature!

from eslint-plugin-promise.