Quoting the author from one of his comments ... "Using private constructors enhances encapsulation". Even in TS nothing even close to encapsulation is going to happen. The private prefix annotation marks the restricted usage of the constructor exclusively within TS environments. In reality the constructor can be invoked from everywhere with the new operator.

Thus, speaking of true encapsulation which covers TS and JS alike, the natural pattern for implementing ConfigurationLoader is a module/namespace of that very name. The module's only exported (hence static as well) method has to be the asynchronous init function which handles the config related bootstrapping and the instantiation of a truly encapsulated ConfigurationLoader class because the latter is accessible just within the module's scope (it never ever is going to be exposed/exported).

Following this pattern `ConfigurationLoader.init` naturally is the only way one can possibly create instances of a truly encapsulated `ConfigurationLoader` class.

Sometimes one should remember that TS does transpile into JS. Picking a pattern which suits both environments is mostly the correct and/or preferable choice. Nobody should get a headache from a hypothetical construct which seems to be possible at first glance just due to how annotations and type tracking work in TS.