1.8 breaks use of third-party promise libraries

[bytenik]

I'm currently developing in TS 1.7, compiling to ES6, and transpiling with Babel to ES5. I use Angular 1.x for my frontend development currently.

I am able to leverage async functions by returning a custom type, QPromise, for which I've written a definition like this:

declare class QPromise<T> implements angular.IPromise<T> {
 constructor(resolver: (resolve: angular.IQResolveReject<T>, reject: angular.IQResolveReject<any>) => any);
 then<TResult>(successCallback: (promiseValue: T) => angular.IPromise<TResult>|TResult, errorCallback?: (reason: any) => any, notifyCallback?: (state: any) => any): angular.IPromise<TResult>;
 catch<TResult>(onRejected: (reason: any) => angular.IPromise<TResult>|TResult): angular.IPromise<TResult>;
 finally(finallyCallback: () => any): angular.IPromise<T>;
}

I then create a JavaScript file with a definition QPromise:

function QPromise(resolver) {
 var $q = angular.injector(['ng']).get("$q");
 return new $q(resolver);
};

While less than elegant, this has been an acceptable shim for now so that I can use async while still using Angular's $q library, which is needed to get Angular digest to occur automatically.

TS 1.8 no longer lets me return a QPromise<T>, complaining: error TS1064: The return type of an async function or method must be the global Promise<T> type.

This all but breaks my ability to work with Angular 1 and still use TS async functions.

[vladima]

pinging Ron Buckton (@rbuckton)

[bytenik]

As an aside, it would be awesome if I didn't have to shim this at all, but rather the compiler could handle newing an instance as well as a concrete type. But it seems like your intent was to move away from that altogether and prefer only the built-in Promise object (which yields my issue above).

[rbuckton]

As of TypeScript 1.8 we are restricting the allowable set of return type's for an async function to only the global Promise.

Unfortunately, this means that you would need to do one of three things:

1. Go one step further in your shim implementation and set the global Promise to the shim if it is not defined.
2. Add a Promise compatible shim library that defines a global Promise.
3. Add a type alias for Promise to a global scope and redefine __awaiter.

An example of [3] might be:

declare global {
 interface Promise<T> extends PromiseLike<T> {}
}
function __awaiter(thisArg: any, _arguments: any, P: any, generator: Function) {
 return new (P || (P = angular.injector(['ng']).get("$q")))(function (resolve, reject) {
 function fulfilled(value) { try { step(generator.next(value)); } catch (e) { reject(e); } }
 function rejected(value) { try { step(generator.throw(value)); } catch (e) { reject(e); } }
 function step(result) { result.done ? resolve(result.value) : new P(function (resolve) { resolve(result.value); }).then(fulfilled, rejected); }
 step((generator = generator.apply(thisArg, _arguments)).next());
 });
}

async function foo() {
}

[bytenik]

Is there a way to make the ES6 included-by-default Promise go away, so that I can supply my own global Promise shim?

[yortus]

relevant: #4692 (comment)

[bytenik]

Yuck. 👎

[bytenik]

What's the logic behind the change away from allowing any newable PromiseLike promise type anyway?

[yortus]

David Pfeffer (@bytenik) see #6631 and the issue it references #6068. It's about alignment to the ES7 spec (ES7 async functions cannot return custom promises). Also, using type annotations to direct emit causes other problems.

[yortus]

David Pfeffer (@bytenik) I think it's a good thing that TS follows ES semantics for async functions, but what's still missing is a straightforward way to polyfill Promise.

[yortus]

David Pfeffer (@bytenik) since ES7 async functions always return ES6 promises, and you'd like to use async function syntax but work with custom promises, a forward-compatible approach might be to use a wrapper around your async functions as suggested here.

[bytenik]

Based on that logic, I agree. Unfortunately until there's a better way to stick my own promise in, I'm stuck with 1.7.

Does the awaiter suggestion above work if I use the built-in es6 library and don't replace the global Promise? Or will I conflict?

[rbuckton]

Keep in mind that the __awaiter helper only exists to downlevel async functions to a version of the ES standard that does not support them. While its perfectly feasible to write a custom __awaiter helper, once async functions are part of an official specification we will emit them natively when targeting that specification version. Any changes to __awaiter wouldn't be reflected when emitting async functions natively, nor would any changes to the global Promise.

Changing __awaiter is a stop-gap solution to fill in support for async functions in a runtime environment without a global Promise. Another solution is to polyfill a global Promise through a library like es6-shim.