getify / native-promise-only

A polyfill for native ES6 Promises as close as possible (no extensions) to the strict spec definitions.

Native Promise Only (NPO)

A polyfill for native ES6 Promises as close as possible (no extensions) to the strict spec definitions.

Intent

The aim of this project is to be the smallest polyfill for Promises, staying as close as possible to what's specified in both Promises/A+ and the upcoming ES6 specification.

An equally important goal is to avoid exposing any capability for promise-state to be mutated externally. The Known Limitations section below explains the trade-offs of that balance.

Usage

To use this polyfill in the browser, include the "npo.js" file (see the instructions in Tests/Compliance section below for how to build "npo.js" if you don't have it already) with your site's scripts. It's a polyfill, which means it will not overwrite Promise if it exists as a global already, so it's safe to include unconditionally.

To use with AMD, import the "npo.js" file module.

To install the polyfill via bower, run:

bower install native-promise-only

To install the polyfill via npm, run:

npm install native-promise-only

Then require the module into your node code:

require("native-promise-only");

Notice that using the module in this way, we don't assign the module's public API to any variable. We don't need to, because it's a polyfill that intentionally patches the global environment (in this case to the Promise name) once included.

If you want to also have a reference pointing to the same Promise global, you can also assign the return value from the require(..) statement, but it's strongly recommended that you use the same Promise name so as to not create confusion:

var Promise = require("native-promise-only");

// Promise === global.Promise; // true!

Other than the below Known Limitations discussion and some browser bugs (such as these) which this polyfill doesn't suffer from, your promises should operate the same in all JS environments.

Exactly like native promises, here's a quick example of how you create and use the polyfilled promises:

var p = new Promise(function(resolve,reject){
	setTimeout(function(){
		resolve("Yay!");
	},100);
});

p.then(function(msg){
	console.log(msg); // Yay!
});

For more on promises, check these blog posts out:

1. Back-story on the hows and whys behind promises (chaining, errors, etc): multi-part blog post series "Promises" by getify (me).
2. Using and enjoying native promises: JavaScript Promises by Jake Archibald.

Known Limitations

A promise object from this polyfill will be an instance of the Promise constructor, which makes identification of genuine promises easier:

var p = new Promise(..);

p instanceof Promise; // true

However, these promise instances don't inherit (delegate to) a meaningful Promise.prototype object for their methods (there is one, it's just mostly empty).

Consider:

var p = new Promise(..);

Object.getOwnPropertyNames( p ); // [ then, catch ]
Object.getOwnPropertyNames( Promise.prototype ); // [ constructor ]

As such, these promises are not really "sub-classable" in the ES6 class / extends sense, though theoretically you should be able to do that in ES6 with the built-in Promises.

To read a full explanation of why, read Part 3: The Trust Problem of my blog post series on Promises.

Briefly, the reason for this deviation is that there's a choice between having delegated methods on the .prototype or having private state. Since the spirit of promises was always to ensure trustability -- that promises were immutable (from the outside) to everyone except the initial resolver/deferred -- private state is a critically important feature to preserve.

Many other ES6 promise shims/libs seem to have forgotten that important point, as many of them either expose the state publicly on the object instance or provide public accessor methods which can externally mutate a promise's state. Both of these deviations are intolerable in my opinion, so this library chose the opposite trade-off: no ES6 sub-classing.

Any trade-off is a shame, but this one is the least of a few evils, and probably won't prove to limit very many, as there are only a limited number of use-cases for extending Promise in the ES6 sub-class sense.

Still Want More?

This project intentionally adheres pretty strictly to the narrow core of Promises/A+ as adopted/implemented by ES6 into the native Promise() mechanism.

But it's quite likely that you will experience a variety of scenarios in which using only native promises might be tedious, limiting, or more trouble than it's worth. There's good reason why most other Promises/A+ "compliant" libs are actually superset extensions on the narrow core: because async flow-control is often quite complex in the real world.

Native Promise Only will NOT add any of these extra flourishes. Sorry.

However, I have another project: asynquence (async + sequence). It's an abstraction on top of the promises concept (promises are hidden inside), designed to drastically improve the readability and expressiveness of your async flow-control code.

You simply express your async flow-control and asynquence creates and chains all the promises for you underneath. Super simple.

asynquence has a custom implementation for the internal "promises" it uses, and as such does not need native Promises, nor does it need/include this polyfill.

Get your feet wet with native promises first, but then when you go looking for something more, consider asynquence (which is vastly more powerful and is still only ~2k!).

Tests/Compliance

Native Promise Only is "spec compliant" in the sense of passing all tests in the Promises/A+ Test Suite.

To run all tests:

1. Either git-clone this repo or run npm install native-promise-only, and then switch into that project root.
2. Run npm install in the project root to install the dev-dependencies.
3. If you didn't get native-promise-only from npm, then from the project root, run ./build.js or node build.js or npm run build to generate the minified "npo.js" in the project root.
4. Finally, run npm test.

Note: Other tests need to be added, such as testing the Promise() constructor's behavior, as well as the Promise.* static helpers (resolve(..), reject(..), all(..), and race(..)), none of which are covered by the Promises/A+ test suite.

Developing a more comprehensive test-suite to augment the Promises/A+ test suite is now another primary goal of this project.

License

The code and all the documentation are released under the MIT license.

http://getify.mit-license.org/

native-promise-only's Issues

on nodejs, exceptions are not shown.

hi, i'm using swagger-node, that uses json-refs, that uses your module.

a couple of weeks ago I noticed that at one point of the code the exceptions stopped appear on console. Then, today I tracked this issue and replacing your module by bluebird, the exceptions are shown properly, and returning to your module the exceptions stops shown.

reproducing the problem is easy, just create a swagger project and change the controller file to not "compile"; the program will stop in the initialization and no output will be shown.

Suggestion: make Promise.prototype aliases of `then` and `catch`

Something like this:

Promise.prototype.then = function () {
  return this.then.apply(this, arguments)
}

Promise.prototype.catch = function () {
  return this.catch.apply(this, arguments)
}

Obviously, I don't mean directly assigning, but you know what I mean. 😉

Uncovered code as of 25-Jun-2014: #1 notify self.state check (line 94)

( https://github.com/getify/native-promise-only/blob/master/lib/npo.src.js#L94 )

The 'if' condition is never true in current tests, so the block containing line 94 is never executed. I will try to add a test to reach this condition.

Uncovered code as of 07-Jun-14: #1 - polyfill logic

This is the first of several issues I'm going to open this morning, outlining different parts of the code that remain uncovered right now. I'm going to break them up by theme.

The first is several uncovered lines and branches in lines 9-29 of npo.src.js ; these are lines that set up the polyfill for different module environments and it's resonable to expect that they're not all exercised on node.js.

Specifically:
because node uses nodelike modules, the AMD handler on line 10 is not exercised;
because typeof global === "object", the 'else' side of the ternary on line 11 is not exercised;
because setImmediate is defined, the 'else' side of the ternary on line 18 is not exercised,
and because Object.defineProperty is defined, the 'else' side of the ternary on lines 27-30 (defining a less-capable version of builtInProp) is not exercised.

Ideally we should environments where each of these are naturally exercised by the lack of appropriate functions (e.g., IE6-8, older versions of node). Failing that, we can probably create synthetic environments that exercise these features.

One risk to consider is, especially on older platforms, using an unexercised implementation of timer() or builtInProp() may cause some of the other tests to fail.

typeof (resolve && reject) doesn't guard against truthy non-function resolve

In the interests of testing both branches of the &&, I created a test class (subclassing Promise) which passes a non-function resolve argument to its executor.

describe("invalid 'resolve':", function() {

function BadResolverPromise(executor) {
    var p = new Promise(executor);
    executor(3, function () {});

    this.then = p.then;
    this.constructor = BadResolverPromise;
}
BadResolverPromise.prototype = Promise.prototype;
BadResolverPromise.all = Promise.all;
BadResolverPromise.race = Promise.race;
BadResolverPromise.reject = Promise.reject;
BadResolverPromise.resolve = Promise.resolve;

it("throws TypeError with Promise.reject", function (done) {
    assert.throws(function() {
    BadResolverPromise.reject(2);
    }, TypeError);

    done();
});
});

As you can see, this is a nasty piece of work that nobody would ever deliberately run in real life -- i.e., it's testing code. However, running it causes the attached test to fail because BadResolverPromise.reject() only calls the passed reject function. The guard on line 305 does not catch the invalid resolve function.

The relevant section of draft spec is CreatePromiseCapabilityRecord steps 8 & 9:

8. If IsCallable(promiseCapability.[[Resolve]]) is false, then throw a TypeError exception.
9. If IsCallable(promiseCapability.[[Reject]]) is false, then throw a TypeError exception.

Similar tests of Promise.all, Promise.race, Promise.resolve all succeed -- finding the expected TypeError exception. I believe that the guard is failing then as well, but the TypeError is thrown by the javascript engine when it attempts to call the non-Callable resolve -- a Number.

Dynamic `this` binding for Promise.* static methods

Per this thread, change the Promise.* static methods to use this instead of statically binding to Promise: https://gist.github.com/domenic/43d3228e141ea225ea6e#comment-1229287

+@domenic

`resolve(..)` should call a thenable's `then(..)` async, not sync.

This isn't a A+ requirement, it's an ES6 requirement.

The problem is, when I "fix" this, it causes lots of other test failures. And also the A+ test suite failures are intermittently different on each run, and sometimes the runner itself crashes. So, basically, this is impossible to track down.

This may in fact be a bug in not adhering to the ES6 spec, but I don't expect to be able to fix it, at least not any time soon. Spent a whole day on it so far, and failed. That's more time than I have to devote to such things.

More info: zloirock/core-js#78

For posterity, these are the offending lines, I believe:

native-promise-only/lib/npo.src.js

Lines 155 to 158 in e18a8de

	_then.call(msg,
	function $resolve$(){ resolve.apply(def_wrapper,arguments); },
	function $reject$(){ reject.apply(def_wrapper,arguments); }
	);

I believe that call is supposed to be deferred (with schedule(..)), but that breaks everything.

Unhandled rejection detection

This is a much much less argumentative idea than the last discussion we've had about it here.

Promise Unhandled Rejection Hook

CoreJS does this using native promises only as the base. In addition native promises do this in io.js and NodeJS (soon) and this would be required to remain complaint to the spec in io.js. Most promise libraries (Q, Bluebird, When, lie etc) have already implemented this.

Cheers!

Microtasks?

I might be covering ground that has already been covered here, but it appears that NPO executes promises on a macrotask queue instead of a microtask queue. I am looking here specifically.

When I run this code in Chrome,

require('setimmediate');  // runs on the macrotask queue
setImmediate(() => console.log('immediate'));
Promise.resolve().then(() => console.log('promise'));

I get the following output (expected):

promise
immediate

When I run the following code,

require('setimmediate');  // runs on the macrotask queue
delete global.Promise;
require('native-promise-only');
setImmediate(() => console.log('immediate'));
Promise.resolve().then(() => console.log('promise'));

the output looks like this instead:

immediate
promise

Admittedly, the spec isn't clear about macrotasks vs microtasks, but it seems that the consensus among vendors is that promises run as microtasks. Here is a Firefox ticket to run Promise callbacks as microtasks. Bluebird schedules Promise callbacks as microtasks -- here is a relevant discussion.

Cross-Browser Support & Tests

Ref #30.

There should be automated tests to assess browser compatibility. At present all I "know" is that ES5 browsers are supported.

Note: need to write tests for the polyfill aspects of NPO, that will live in the NPO repository. This is in contrast to the Promises-ES6 tests, which have been pulled out into a separate repo.

A thenable should be synchronous?

The test case:

var x = 0,
    thenable = {
        then: function () {
            x = 1;
        }
    };
Promise.resolve(thenable);
console.log(x); // 0 in Chrome36, but 1 in Aurora31 and your polyfill

What is right?

Create tag for v0.7.6-a

After last commit you did not created tag for this (and therefore i could not point bower on last specific version). Could you?

Promise.resolve(1) throws on Android 4.0

Promise.resolve(1) throws on Android 4.0:

TypeError: Not a promise
  at TypeError (unknown source)
  at new a (http://jquery-master.l/external/npo/npo.js:5:1481)
  at Function.<anonymous> (http://jquery-master.l/external/npo/npo.js:5:2700)
  at http://jquery-master.l/dist/test-promise.html:18:18)

This is with native-promise-only 0.7.7-a.
The tested site:

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <title>jQuery.when on Android 4.0 test page</title>
</head>
<body>
    <script src="../external/npo/npo.js"></script>
    <div id="result"></div>
    <style>
        #result {
            white-space: pre-wrap;
        }
    </style>
    <script>
        var res;
        try {
            res = Promise.resolve(1);
        } catch (e) {
            res = e.stack || e.message || e;
        }
        document.getElementById('result').textContent = res;
    </script>
</body>
</html>

I thought the jQuery test error was related to #38 but it turns out it didn't fix it.

Error when running through babel compiler

When npo.src.js or npo.js is run through babel the following line:

})("Promise", typeof global != "undefined" ? global : this, function DEF() {

becomes

})("Promise", typeof global != "undefined" ? global : undefined, function DEF() {

This causes this line to die, as context is undefined

 // special form of UMD for polyfilling across evironments
      context[name] = context[name] || definition();

Script to replicate issue:

var fs = require('fs'),
    babel = require('babel-core');
babel.transformFile('./node_modules/native-promise-only/lib/npo.src.js', function (err, result) {
    if(err) {
        return console.log(err);
    }
    fs.writeFileSync('.temp.txt', result.code, {
        encoding: 'utf8'
    });
});

Benchmark NPO's performance against other libs

Need to get an idea on where NPO's performance stands in relation to other polyfills:

https://github.com/nlindley/perf-promises

nlindley/perf-promises@2828c0c

Debugging strategy

Consider this:

myService().then(function(){
   doSomething(); // may throw an error, e.g. `JSON.parse`
});

Most promise libraries include a way to debug promise based code without having to always add a .catch(function(e){ throw e}) handler, some examples:

• Native promises in Firefox use garbage collection in order to track unhandled rejections and log the errors to the console.
• Libraries like Q use .done to signal that a chain is terminated and rejections that got to that point log.
• Bluebird promises track unhandled rejection approximately (in a way that practically always works).

What is the correct way to deal with this with NPO? How should one proceed when debugging this sort of thing?

Research: a debug build of NPO that includes better error tracking

Per discussions in #23 with @benjamingr

handling uncaught exceptions

If an exception is thrown from a resolve handler it seems to be either swallowed or emerges many seconds later on the console. Is there a way to get instant feedback from uncaught exceptions?

Sequence of .then() calls with Promise.all

I have cleaned up one of the tests that shows a difference in behavior between NPO and v8 -- since this is the version of v8 which is known not to pass the Promises/A+ suite, I was initially inclined to suspect that this is reacting to a problem in v8. Now I am not so sure, and I would appreciate guidance. (/cc @domenic @allenwb )

Here is the test:

it("should should execute 'then' methods in sequence", function(done) {
    var p1 = Promise.resolve(100),
        p2 = Promise.resolve(200);

    var sequencer = [1];

    // Point "A"

    p1.then(function afterOne(resolved) {
        assert.deepEqual([1], sequencer);
        sequencer.push(2);
    }).catch(done);

    // Point "B"

    Promise.all([p1, p2]).then(function afterAll(resolved) {
        assert.deepEqual([1, 2], sequencer);
        sequencer.push(3);
    }).catch(done);

    // Point "C"

    p2.then(function afterTwo(resolved) {
        assert.deepEqual([1,2,3], sequencer);
        sequencer.push(4);
    }).then(done).catch(done);

    // Point "D"
});

My expectation is that the three functions passed to then will be enqueued and eventually executed in sequence: ( afterOne, afterAll, afterTwo ). However, I am concerned that my expectations are coloring my reasoning as I read the spec.

According to 25.4.4.1 step 9.o all invokes then on each of the promises in its argument. (Technically there's an intermediate step where Promise.resolve is called on each argument, but since p1 and p2 were constructed by the same Promise constructor as Promise.all, Promise.resolve just returns them without constructing new promises.)

According to 25.4.4.3 step 12, when then is called on a promise in the state "fulfilled", a task to call its onFulfilled handlers is enqueued immediately.

Both p1 and p2 are constructed by Promise.resolve() so they begin in the "fulfilled" state.

I would expect the state of the "PromiseTasks" queue to evolve as follows:

   Point A: []   // empty queue
   Point B: [ afterOne ]
   Point C: [ afterOne, resolveElement1, resolveElement2 ]
   Point D: [ afterOne, resolveElement1, resolveElement2, afterTwo ]

After control flow leaves the test function, I would expect tasks to be consumed from the "PromiseTasks" queue in FIFO order. The question is, what happens when resolveElement2 finishes executing?

According to 25.4.4.1.1 step 10, when remainingElementsCount.[[value]] has dropped to zero, the parent Promise created by Promise.all should have its promiseCapability.[[Resolve]] function called. This will eventually trigger a call to the only function in its onFulfilled slot, namely afterAll.

The question is, can resolveElement2 synchronously call afterAll (since it is running in the PromisesTask handler, not from user code) or must it enqueue the call to afterAll? This is detectable by user code as above, where the numbers pushed to sequencer distinguish between the call order of (afterOne, afterAll, afterTwo) vs. (afterOne, afterTwo, afterAll)

I started writing this thinking that my test was correct, and afterAll should be called before afterTwo. Midway through writing this, I flip-flopped and started to think that afterTwo should be called before afterAll. Now I am merely confused.

Comments very much appreciated.

Uncovered code as of 07-Jun-14: #2 - checkYourself

TBQH I was a little disappointed that this didn't wind up calling wreckYourself()

Seriously, though, the if() test on line 146 is never true, so the block containing line 147 is never executed.

I am curious about this: is this a provable never-happens condition, or is it a hole in the promises-aplus-tests, or even a hole in the specification?

In any case I certainly don't advocate removing the guard yet. Eventually if we can prove self.state is never 0 at that point, then the guard and return can go, simplifying the code a bit.

Android 4.0 issue

Specifically this, might occur on other clients, but Android 4 doesn't play well when Object.defineProperty is used to set the prototype, i.e. the __NPO__ isn't being set for these clients

Solution for now was to replace https://github.com/getify/native-promise-only/blob/master/lib/npo.src.js#L283 with

Promise.prototype = PromisePrototype;

Module with unminified code should be exported by default

To improve debuggability, please export a module that is loaded using unminified code by default. That is, the following module should be loaded using unminified code:

require('native-promise-only');

If desired, the end user can enable a minifier if bundling code targeted for the browser.

Thanks.

Working on tests for Promise.all

A note - I started working out the behavior for Promise.all, on a branch here:

https://github.com/smikes/native-promise-only/tree/test-Promise-all

Support IE8

Do not use Object.defineProperty in IE8

builtInProp = Object.defineProperty ?
    function builtInProp(obj,name,val,config) {
        return Object.defineProperty(obj,name,{
            value: val,
            writable: true,
            configurable: config !== false
        });
    } :
    function builtInProp(obj,name,val) {
        obj[name] = val;
        return obj;
    }

IE8 implemented the Object.defineProperty that could only be used on DOM objects

Fate of promises-spec tests?

Starting a new thread so we don't CC everybody who got involved on the PR.

What do you want with this PR? I originally got involved because I wanted to learn what the promises spec said, and it seemed like a good way to do that was to help you increase code coverage of your promises polyfill.

That morphed into writing some tests that assess compliance with the ES6 spec, which are maybe worth pulling out into their own project.

I can make the three constructor tests pass by adding a little bit of logic to the beginning of function Promise()

    if (typeof executor !== "function") {
        throw TypeError("executor must be a function");
    }
    if (typeof this !== "object") {
        throw TypeError("this must be an object");
    }
    if (this.__isAPromise) {
        throw TypeError("this must not already be a Promise");
    }
    this.__isAPromise = true;

That's not to say that this ensures spec compliance, just that this code suffices to make NPO pass this test suite.

Should I commit this to the PR?

Typo in description

A polyfill for native ES6 Promises that as close as possible (no extensions) to the strict spec definitions.

Should probably be: A polyfill for native ES6 Promises that is as close as possible (no extensions) to the strict spec definitions.

Edit: you'll need to adjust the GH repo description also, that's why this isn't a PR.

The UMD for npo doesn't properly polyfill

Using npo in its current form in node (or in a browser that has AMD, for that matter) breaks with how polyfills are supposed to work (explicitly patching the env), making it fail as a real polyfill.

Fix that. Use/make a polyfill version of the UMD pattern.

Promise finally not supported

In IE 11, when running the following code:
Promise.resolve().then(function(){console.log('hi');}).finally(function(){console.log('victory');});

It results in the error:
Object doesn't support property or method 'finally'

From looking at the code, it appears that isn't supported. Is that right? If so, any plans to add support?

What is correct execution sequence when attach multiple handlers to the same promise.

The test case(in general, bad case...):

var p = new Promise(function(resolve, reject){
    console.log("start");
    resolve("");
});

p.then(function () {
    console.log("1-1");
}).then(function () {
    console.log("1-2");
}).then(function () {
    console.log("1-3");
});

p.then(function () {
    console.log("2-1")
}).then(function () {
    console.log("2-2");
}).then(function () {
    console.log("2-3");
});

The result of Firefox 35.0a1 and native-promise-only :

"start"
"1-1"
"1-2"
"1-3"
"2-1"
"2-2"
"2-3"

The result of Chrome 37.0.2062.94 , @domenic's reference-implementation (code) and native-promise-only:

"start"
"1-1"
"2-1"
"1-2"
"2-2"
"1-3"
"2-3"

Which is correct?

is it possible for Promise.resolve and Promise.reject to be synchronous?

Uncovered code as of 25-Jun-2014: #2 tests of 'resolve' 'reject'

The tests that a subclassed Promise constructor is passing reasonable 'resolve' and 'reject' functions are not exercised by current tests.

(An example is https://github.com/getify/native-promise-only/blob/master/lib/npo.src.js#L326 )

I will add tests for this; it wasn't a high priority earlier but it's the only uncovered code left, other than APM and polyfill related boilerplate (discussed in a different issue).

is it possible to have private state AND sub-classability?

Investigate https://github.com/lvivski/davy per: https://twitter.com/lvivski/status/463732560456351744 +@lvivski

Promise.prototype.toString

https://github.com/petkaantonov/bluebird/blob/master/src/promise.js#L92-L94

Uncovered code as of 07-Jun-14: #3 - typeof x !== 'function' guards

The guards in checkCapability (lines 217-221) and at the head of Promise() (lines 239-241) are not exercised by current tests.

I see justification in the ES6 draft spec for requiring that the argument to Promise() is a Callable, and will add that check to constructor.js

I am not sure how to test that resolve, reject are callable, since (nominally) the Promise library itself is always providing these functions, so that may remain uncovered.

Workaround to make spec-conformant Promise.prototype.then

Right now Promise.prototype.then doesn't make sense in the NPO context, because the spec expects a protypal inheritance / object-oriented style, but NPO uses closures for trustability/safety.

What I mean is, in order for this to work:

  Promise.prototype.then.call( promise, whenResolved )

the then function could not be a closure, and some information about the internal state of promise would have to be exposed and writeable (so that then could add whenResolved to its list of resolvers ).

But... we could do it in this (sneaky? possibly evil? way):

  Promise.prototype.then = function ( whenResolved, whenRejected ) {
         // guards to prevent infinite recursion

         // delegate to 'this' object's 'then' method which can see the closure
         this.then(whenResolved, whenRejected);
  }

It completely violates the spirit of the spec, which is that a Promise is a normal object with legible state that can be acted on by methods defined on its prototype. IMO that shouldn't be written into the spec; the spec should allow Promises implemented in several different ways to be conformant.

But it fulfills the letter of the spec, in providing the expected behavior when Promise.prototype.then is applied to a promise using its .call() method.

browsers support information

Please, supply browsers support information.

consider a "scheduling queue" instead of individual timers

same idea as here: getify/asynquence#39

need a perf benchmark to justify if this really helps. :)

Ponyfill support?

First of all, thank you for all the work on this module. It's fantastic.

In my case I don't want native-promise-only to set window.Promise. I'd rather only have native-promise-only hand me the native implementation if it exists or its implementation if the native one does not exist. Have you considered providing this option? If you're not interested, I may release a native-promise-only-ponyfill with code similar to the following:

var Promise = window.Promise;

if (typeof Promise === 'undefined') {
  Promise = require('native-promise-only');
  // native-promise-only will set window.Promise if it doesn't exist. In our case,
  // we don't want to be setting globals so we'll return the global back to undefined.
  window.Promise = undefined;
}

module.exports = Promise;

Thanks!

Scheduling bug affects inter-promise sequencing

Test case:

var resolveP1, rejectP2;

(new Promise(function(resolve, reject) {
    resolveP1 = resolve;
}))
.then(function(msg){
    console.log(msg);
});

(new Promise(function(resolve, reject) {
    rejectP2 = reject;
}))
.catch(function(msg){
    console.log(msg);
});

rejectP2("A");
resolveP1("B");

Factor out Queue() library?

The Queue() function from lines 34-64 looks like it might be usable as a general-purpose module. My understanding is that you switched to a linked-list model instead of arrays because dynamically adding elements to arrays gave bad performance (space, speed, both?)

Factoring out Queue() would both allow people to leverage that performance in similar situations and allow Queue() to be tuned independently on different Javascript engines.

Make tests for everything not in the promises/a+ test suite

RE: domenic/promises-unwrapping#68

Need tests for:

• Promise() constructor
• Promise.resolve(..)
• Promise.reject(..)
• Promise.race(..)
• Promise.all(..)

AMD?

Hi, when using this polyfill with requireJS in PhantomJS environment I am getting:

Error: Mismatched anonymous define() module: function (){return b[a]}
http://requirejs.org/docs/errors.html#mismatch

The expected here is that Promise is available globally, just like the native behavior and no error occurs.

Any reason for using AMD in a project that is suppose to act as a polyfill of standards?

`Promise.all(..)` and `Promise.race(..)` are busted

Bug:

Promise.all([
   Promise.resolve(10),
   Promise.resolve(20)
])
.then(function(msgs){
   msgs; // [ , , 20 ]  --> should be [10,20]
});

---

Diagnosis: the iteratePromises(..) function now uses a for-loop via some perf optimizations per #8, so now its closure is busted. Duh.

Missing tag for version 0.7.8-a used by jQuery

jQuery 1.12.4 ships a minified-only npo v0.7.8-a with no source available, which makes jQuery 1.12.4 not Open Source, and not suitable for Debian to boot.

The npo repository does not have a git tag corresponding to v0.7.8-a and does not contain the minified compilation output, so I cannot find out the correct source code myself.

This makes jQuery 1.12.4 non-redistributable under OSS rules.

Better native support detection?

What's your take on whether to replace (broken) native Promise implementation? Is a quick check on global Promise enough?

https://github.com/jakearchibald/es6-promise/blob/master/lib/es6-promise/polyfill.js

Also Jake Archibald's implementation does extends Promise.prototype, but only on then/catch, is that a more acceptable evil in your opinion? (I have read your blog series on your stand, but just wondering)

PS: So far none of the module I used that rely on Promise actually extend Promise, but I wonder about NPO compatibility (in possible future) if prototype.then and prototype.catch are missing.