TypeScript helper separation

[guybedford]

Does TypeScript have a runtime-style module? Or are helpers concatenated per-build?

Currently the build is inlining all helpers, which is obviously not ideal.

[vladima]

@guybedford Currently we've made a few modifications in TypeScript (should be available in 1.6)

• we emit helper inside the module so it does not mess up module kind detection logic in SystemJS
• there is a noEmitHelpers compiler options that suppresses generation of these helpers so user can provide its own global implementation of __extends, __decorate etc.

Is it enough for your scenarios or you would expect runtime library to be a module so in case if user writes some code that uses runtime helpers we would emit some code like

System.register(["typescript-runtime"], function(exports_) {
    var typescriptRuntime; // set in setter
    var __extends = (this && this.__extends) || typescriptRuntime.__extends; 
    ....

})

[pkozlowski-opensource]

there is a noEmitHelpers compiler options that suppresses generation of these helpers so user can provide its own global implementation of __extends, __decorate etc.

@vladima are you guys planning on shipping a file with all the global helpers?

[guybedford]

@vladima that sounds great. A runtime library module would definitely be nice to reference rather than relying on globals.

Further than that, Babel has a transform option to output modular helpers:

System.register(['helpers/core', 'helpers/class'], function(exports_) {
  var __extends, __decorate;
  return {
    setters: [
    function(core) { __extends = core.__extends; },
    function(class) { __decorate = class.__decorate; }
    ],
  };
});

etc. That said this now has the reverse problem that too much granular modularity actually becomes itself a performance bottleneck - something inbetween the Babel approach and a single runtime library might also be useful to split up just the needed helper modules as well (I guess only useful if the TypeScript runtime is very large to split it up?)

[vladima]

we are considering this as an option but we need to figure out some questions about the format of helper: should it be just a set of globals or it should be a UMD module. If helper library is a module then it affect the codegen - we need to inject a runtime library in the list of modules

[guybedford]

@vladima the helper library can be treated just like any other library - distributed however the consumer desires - UMD / CommonJS / ES6. In terms of how we run TypeScript in this project, we would do a single file transpile and then set a custom path to the runtime library (my/custom/helper/base sort of like a base path to the helpers being at my/custom/helper/base/core etc), then most likely using a global, CommonJS or UMD build.

In terms of generating the helper library as part of a full tree build, then yes it would need to be injected for those cases using a standard format.

[jods4]

Any news about how we could get a prelude containing the helpers required by our code to append it once to built files?

Passing --noEmitHelpers is part of the solution, but currently we concatenate fixed helpers that we copied from TS source.

This is fragile. For instance, TS 1.8 has changed its code for __awaiter, so our code broke, without build-time error of course: we caught it in testing.

We use gulp to build, it would be nice if TS could provide a file with just the helpers required by our code in its results. Babel does that for instance.

Alternative: let us use babel for all transpiling by providing a new ESnext target, so that no TS helpers at all are required.