Bluebird: Standard API

[julien-f]

I think I once saw an API to restrict Bluebird to the standard API without all its utilities but I can't find it on the new website, is it still the case?

[phpnode]

it wasn't a separate build, I think it was a joke comment by Petka that you could just delete all the non standard methods from Bluebird and it would be spec compatible (apart from subclassing). In practice what is the benefit apart from slightly smaller builds?

[julien-f]

My use case is I'm using the standard Promise object but with Bluebird implementation (global.Promise = Bluebird) to have better performance and less memory leaks :p

The benefit of restricting the API is not for smaller builds but to avoid using non standard features (by me and my team).

[benjamingr]

@julien-f

You can always subclass the "standard" promise and add bluebird extension methods later to the subclass if you end up using a method that isn't standard.

If I were you I'd just use the regular bluebird API. That said:

Promise.resolve Promise.reject Promise.all Promise.race Promise#then Promise#catch and that's about it.

[petkaantonov]

yep you can just delete the methods you don't want to use from the Promise.prototype

[lextiz]

@petkaantonov It would be very useful to add a build/runtime flag to limit the bluebird API to standard Promise subset: large projects that are developed by multiple teams and want to be compliant to the ES6 standard would benefit from this. You say (https://github.com/petkaantonov/bluebird/issues/217#issuecomment-44378046) if one wants to use ES6 subset he can just use it, but this is not simple to enforce when the code is developed by multiple teams. What do you think?