Call for contributors

[julien-f]

Hi everyone,

I'd like this library to be the best toolbox for promises, and for that I need you!
Something like Bluebird wonderful extensions but compatible with any promise implementations complying with the standard.

Requirements for this lib:

• work both in Node and browsers
• only require a standard Promise implementation (new Promise(), Promise.resolve(), Promise.reject() & Promise#then())
• be as small as possible (currently less than 200K with deps, 20K if only the necessary JS files are considered)
• all methods should be tested
• do not reinvent the wheel (do not implement forEach(), map() or reduce() just for ease-of-use, that's why arrow functions are here for)

Anyone interested in co-maintaining this repo?

//cc @blakeembrey, @benjamingr, @floatdrop, @ForbesLindesay, @sindresorhus

PS: I am fully open to critics regarding the current state of the library, for instance I chose to use pseudo-methods (to take advantage of the :: operator) but it may not be ideal everywhere.

[divmain]

@julien-f, big fan of this lib, I would love to pitch in. Anything I should before I get started?

[benjamingr]

An optimization like bluebird's would require closure-less promisification (impossible with native promises) and a PromiseArray like abstraction for a fast .all and combinators (also require a lot of code).

If performance is not a goal, this is nice! I would not rely on :: as it's one of the most contested proposals and is unlikely to progress anytime soon.

Instead I would provide two versions:

• a require("lib-name/global") that extends the native promise prototype on all promises.
• a var Promise = require("lib-name") that provides a native promise subclass with all the combinators.

[julien-f]

@divmain nope, not really, you can look for the help wanted label, or propose new ideas depending of you needs.

Feel free to ask questions or criticize, everything is open for debate :)

[julien-f]

@benjamingr, I'd like to have good perf but also keep the code small and easily understandable, I have no ambitions to beat Bluebird at that game :p

That's too bad for the :: proposal, I really liked the idea of decoupling objects from their “methods” :/

I'm not fond of the idea of extending the native prototype but if users ask for this I can change my mind.

The second idea is interesting, I think I'll implement it soon :)