It should have:

• a summary of each implementation.
• how to download
• how to use
• known bugs

If promise's .then() method is invoked after the promise has been fulfilled or failed it returns undefined.

It must return a promise to be fulfilled when callback is complete.

According to the Promise/B standard .when() method should recive a success and error callback.

It should provide a very basic but extensible Promise/A pattern implementation.

Required:

• promise: Object dedicated to handle callbacks through the .then() method
• deferred: Object dedicated to promise control. It has .resolve() and .reject() methods.
• factory: Creator of deferred objects.
• extension method: A simple way to extend the whole library without modify it.

Nice to have:

• .isPromise method
• when method. It will recive any value and return a promise wrapping it.

We need a more utility-focused implementation over Base.

A new module has to extend Base promises and add some utility methods:

Promise

• isResolved()
• isRejected()
• isCompleted()
• fin(callback): A callback passed to this method will be called even if the promise si resolved or rejected. It has no effect over promise's value.
   * spread(callback, errback): Like .then() but If the value of the promise is a array it will pass them to the callback as arguments.

Factory methods

• resolved(value): Return a resolved promise with it's argument as value.
• rejected(reason): Return a rejected promise with it's argument as reason.
• all(values): Recives a array of promises/deferred/values and returns a promise to be completed when they all are resolved.

Nice to have

• timeout(ms): The promise will be rejected if after ms milliseconds it's not completed.

How to reproduce

var obj = Object.create({ a: 1 });
var wrapper = deferred.adapt(obj);
assert.ok(wrapper.a === 1);

It will be useful to have sugar syntax methods to modify the promise value:

• get(key): Will return a new promise who will be fulfilled extracting [key] from the original promise's value. Same as .then(function(value) { return value[key]; })
• set(key, obj): Will modify promise's value setting key property. Same as .then(function(value) { value[key] = obj; return value });
• method(name, args): Will invoke promise's value name method and fulfill the returned promise with method's return value. Same as .then(function(value) { return value[method].apply(value, args); });
• invoke(args): Will invoke the value passing args as it's arguments, the returned value will be used to fulfill the new promise. Same as .then(function(value) { return value.apply(null, args) };
• flat(): If the promise value is an multi-dimension array it will reduce it to a one-dimension array.

As the project has many implementations one build system for each one is mandatory.

Need a simple method to launch every build o just a specific of one implementation if it's tests passes.

It's difficult to use Promises with Node.js native API. We need methods to reduce the promise-to-CPS compatibility code.

• callback(): This method should return a CPS callback than resolves or rejects it's promise. As promises can handle only one value the second argument only will be used as the value.
• static adapt(): This method should decorate the recived object. The decorator should add one last argument to each call to it's methods, this argument will be a CPS callback.
• *adapt()": Just like static .adapt() but it's applied to the promise's value.

The idea behind BDD is to describe the behaviour with story-like sentences

When a deferred object's #promise's property method #then is invoked without arguments should return a promise who will success if the original promise succeed.

Right now the messages are a bit messy

Basic promise implementation Base deferred component object #promise property #then method return value should return a promise who will success if the original promise succeed

Many times while doing TDD or debugging test cannot be executed because previous tools (like jsHint) founds a minimal error (missed semicolon, wrong identation...).

There must be a way to diferentiate the test to be executed while developing from those than must be executed before each commit.