Each helper in separate module about tslib HOT 10 CLOSED

Just because they do doesn’t mean that this wouldn’t be a good change. This does nothing for browserify users or people using older versions of webpack.

This solution is both relatively easy to switch to and the support is guaranteed.

from tslib.

I am also finding this to be a problem when publishing many small typescript modules. Ideally each utility would have it's own namespace require('tslib/$NAME').

Inlining the code directly means (when publishing a bunch of small modules) a bunch of code is duplicated, however when you use importHelpers it means you are incurring at least 2kb gzipped, which is a lot to ask for a module that is say 1kb gzipped.

I would personally advocate the approach taken by just however everything doesn't necessarily need to be in it's own published package.

It would be even cooler if these utilities could be used (without risk and with official support) in non typescript files to even further decrease duplication. For example in many of modules I require something like just-extend when I could easily use tslib.__extends if it were supported.

from tslib.

So you are importing the whole tslib there.

Again, why not put each helper in its own module and do something like this:

var _extends = require("tslib/lib/extends");

from tslib.

Honestly, there is not a lot of code in this library. While the output does not lend itself to tree-shaking, your loader will only include it once so it doesn't seem like a code size issue.

@aluanhaddad "a lot of code" is relative, if I write a 10 line script for the web that uses only _extends, why would I incur a penalty of 200-line tslib.

from tslib.

First, install tslib:

npm install tslib

Then add importHelpers: true in your tsconfig.json:

{
  "compilerOptions": {
    "moduleResolution": "node",
    "module": "commonjs",
    "target": "es5",
    // ...
    "importHelpers": true // <-------
  }
}

Now when you compiler *.ts file, it may looks like this:

var tslib_1 = require("tslib")

tslib_1.__awaiter(...)

tslib_1.__extends(...)

from tslib.

Honestly, there is not a lot of code in this library. While the output does not lend itself to tree-shaking, your loader will only include it once so it doesn't seem like a code size issue.

Also, some of the functions reference each other, meaning that if the package were split, they would need cross referencing imports which would result in a more complex multi-module format export strategy than what is already in place.

from tslib.

@streamich if you don't use importHelpers then typescript will inline only the methods which you actually use. importHelpers is to reduce helper methods being inlined across multiple modules.

from tslib.

@frankwallis I know that, but it will inline those in each file though.

from tslib.

Is there a reason that existing bundlers can't just do a good job here with tree-shaking? We provide both ES2015 and UMD outputs. Both Webpack and Rollup should be able to do a decent job here.

from tslib.

Yeah, I'm against the idea of splitting this into sub-modules too. Module bundlers can handle tree shaking tslib just fine nowadays (we have tests for in in #126).

I'm going to close 👍🏻

from tslib.