Is this project dead from community??

[JounQin]

Node native ESM spec is not applied and this is causing a lot of compatibility issues, when I use pure ESM, I have to enable importHelpers: false because tslib's configuration is invalid.

#170

#173

#161

Why you maintainers can't see these?? What the resistance stopping you from fixing them?

There are a few PRs fixing those issues but received no feedback, it's just disappointing.

cc Daniel Rosenwasser (@DanielRosenwasser) Orta Therox (@orta) Ron Buckton (@rbuckton) ExE Boss (@ExE-Boss)

[weswigham]

What the resistance stopping you from fixing them?

Most tools have very bespoke behavior, and we care about backwards comparability a lot.

• tslib.es6.js can't be renamed or moved (and probably should remain standalone with all the implementations within it) because it's a direct file people have referenced/included in builds for a long time, long predating any kind of native esm support, and to change any of that would break those users.
• Likewise, for tslib.js.
• modules/index.js was added and exists for modern node so someone can import {__helper} from "tslib" in native esm in node and have it actually work, since node can't detect tslib.js's bespoke export assignment factory for named export hoisting.
• The module condition was provided for webpack so it knows it can just use the esm-syntax tslib.es6.js everywhere in the build, and not bother with the dual-format chicanery node needs.
• Browsers also don't read package.json type fields, so tslib.es6.js has always worked for browsers directly, too.

So that only leaves bespoke other runtimes/bundlers whose behavior don't match anything I've already listed, which we don't really explicitly support, and definitely don't want to break other users to support. So we take proposed changes to help those runtimes, sure; but not at the expense of existing support.