Ah, my apologies. I was not clear enough with my phrasing. What I meant is that the async IIFE you're proposing is semantically equivalent to the chained promises I presented in the article—just with some nice syntax. If we were to transform the async IIFE into their chained equivalent, then the points I made in Workaround #1 are still applicable—again, just with nicer syntax.
My main issue lies in the atypical semantics of returning Promise<this> (assuming such syntax exists) from the constructor. Normally, I expect that a class constructor returns an instance of that class. However, using async IIFEs (or chained promises otherwise) goes against this expectation since it does not return this but Promise<this> instead.
The deal breaker, then, is the fact that although this technique is allowed and correct in JavaScript, it is difficult to deny that it is unexpected unless documented. In my opinion, it is best to explicitly tell the user (through the type signature) that the function returns Promise<this> rather than relying on external documentation to know that the constructor produces Promise<this> rather than this.
This is exactly why I recommended static async functions: their type signature does not hide the fact that it returns Promise<this>. This is not the case for the constructor, which TypeScript assumes to (implicitly) return this, not Promise<this>.
Ah, my apologies. I was not clear enough with my phrasing. What I meant is that the
async
IIFE you're proposing is semantically equivalent to the chained promises I presented in the article—just with some nice syntax. If we were to transform theasync
IIFE into their chained equivalent, then the points I made in Workaround #1 are still applicable—again, just with nicer syntax.My main issue lies in the atypical semantics of returning
Promise<this>
(assuming such syntax exists) from theconstructor
. Normally, I expect that a class constructor returns an instance of that class. However, usingasync
IIFEs (or chained promises otherwise) goes against this expectation since it does not returnthis
butPromise<this>
instead.The deal breaker, then, is the fact that although this technique is allowed and correct in JavaScript, it is difficult to deny that it is unexpected unless documented. In my opinion, it is best to explicitly tell the user (through the type signature) that the function returns
Promise<this>
rather than relying on external documentation to know that theconstructor
producesPromise<this>
rather thanthis
.This is exactly why I recommended static
async
functions: their type signature does not hide the fact that it returnsPromise<this>
. This is not the case for theconstructor
, which TypeScript assumes to (implicitly) returnthis
, notPromise<this>
.Even if it's typed as
Awaited<ClassName>
?As far as I know, TypeScript does not allow the
constructor
to be directly type-annotated. As of writing, the compiler produces the following error: