Closed streamich closed 3 years ago
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(...)
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");
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.
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
.
@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.
@frankwallis I know that, but it will inline those in each file though.
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.
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.
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.
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 👍🏻
Why not put each helper in a separate module and let TypeScript
require
only those that are actually needed?