Does installing tslib actually do anything with esbuild?

[GitMurf]

Given that esbuild does not currently support transforming es6+ syntax to es5, and tslib main purpose is to add helpers for older es5 browsers etc., does installing tslib in a project that is using esbuild to compile/bundle my TS code even have any impact? Or does tslib only help if I use the tsc to compile my TS code, which at that point defeats the purpose of using esbuild, correct? Or is there a way to use a combination of tsc + tslib + esbuild to get the best of all worlds?

In summary, I guess my question is whether tslib actually does anything if I am using esbuild for my project?

Thanks!

[evanw]

No. tslib is entirely unrelated to esbuild, and installing it doesn't change esbuild's behavior at all.

You are welcome to compile your code with tsc to JavaScript and then bundle the JavaScript with esbuild. You will lose the speed benefit of esbuild but it could still be useful if you need your code bundled (since tsc is not a bundler). Or you are welcome to use another tool instead. I believe SWC is supposed to support bundling and compiling to ES5 for example, although I haven't tried it myself: https://swc.rs/.

[GitMurf]

Thanks @evanw for the quick response! Exactly what I needed. esbuild is operating exactly how I want it to :) I am all about the speed and with my electron app I am targeting es2017 anyways so therefore tslib seems to be pretty much obsolete for those purposes as most of it was meant for compiling to older es5. I just wanted to make sure I wasn't missing out on something or misunderstanding how tslib works and relates to tsc and esbuild.

I currently am using esbuild to compile / bundle straight from my TS code and then only use tsc when I am building for prod and I use the noEmit flag so it still doesn't actually do the compiling of the TS files but just the type checking before letting esbuild do its magic :) Curious, in your opinion is that a decent approach?

I will close this issue.

[jahorton]

In case anyone finds this via search and wants a way forward in ES5, we've figured out how to move forward with this for my main project:

• change(web): common downcompile helpers 🧩 keymanapp/keyman#8904

It's probably a bit hacky, but this relies on two details:

1. esbuild version 0.15.16 and above now support alias options in their build configuration parameters. With this, we can alias tslib imports to a custom package that wraps the ES5-based tslib.js file found in the tslib distribution. esbuild can't handle the object-destructuring modules/index.js syntax in ES5 mode, as it requires ES6.
2. To ensure that we don't reproduce the same problem, the wrapping package's tsconfig.json uses "Node" module-resolution mode, not "Node16" or higher - we wish to ignore import maps. This instead connects us to tslib's package.json main entry, which is the CommonJS import leading to the pure-ES5 tslib.js, which esbuild can handle.

For further enhancements, we've also developed this one:

• feat(web): downcompile helper treeshaking 🧩 keymanapp/keyman#8964

As is, the wrapping package approach unfortunately does not work well with esbuild treeshaking... but we can utilize esbuild's plugin architecture and the patterns in the backing tslib script to do it ourselves without too much issue. This requires two plugins and an extra build pass for the first:

1. First phase: Sets write: false, scans for all tslib helper function names used by the codebase, then determines which ones can be safely tree-shaken. An 'ignore' pattern may also be set - we use this to avoid picking up names from a file defining embedded worker code.
2. Second phase: now that we know which tslib helpers can be eliminated, the second plugin looks for tslib.js and erases the relevant method definitions and the exporter statements.