Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Rule proposal] Limit usage of promise API to current ECMA standard #46

Closed
lidortal opened this issue Nov 20, 2016 · 6 comments · Fixed by #502
Closed

[Rule proposal] Limit usage of promise API to current ECMA standard #46

lidortal opened this issue Nov 20, 2016 · 6 comments · Fixed by #502

Comments

@lidortal
Copy link

Today there are many libraries that enhance the ECMA standard, like bluebird.
It will be very helpful if we can enforce only usage of the standard and not super-set.

@xjamundx
Copy link
Contributor

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?

@tamirmen
Copy link

tamirmen commented Nov 21, 2016

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".

@xjamundx
Copy link
Contributor

xjamundx commented Nov 22, 2016

@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?

@lidortal
Copy link
Author

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.

@ShimiT

This comment was marked as off-topic.

@macklinu
Copy link
Contributor

macklinu commented Feb 8, 2018

#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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants