chore: Support Node.js ES Modules via conditional exports

[ExE-Boss]

I’ve also added exports mappings for tslib/tslib.js → tslib/tslib.cjs.

---

Supersedes and closes #44

Resolves #81; closes #84

[weswigham]

I'm unsure if we'll take this as-is, since it's a break to the API surface of the module (mostly the renaming of files). It might make sense to make a subfolder with a package.json containing type: module and a symlink to the es6 module in the root (or symlink the root to the subfolder, depending on symlink behavior), instead, this way the files are still in all the places consumers expect.

cc @rbuckton

[dasa]

ping 😄

[vikerman]

Symbolic links don't work since the final resolved path is considered. Also you can't publish symbolic links on npm.

A solution might be to add a prepare step that copies tslib.es6.js to tslib.mjs and the have the conditional export for import point to the .mjs file. I can create a PR if that's acceptable.

[ExE-Boss]

A better option is to just do a ./tslib.js → ./tslib.cjs and ./tslib → ./tslib.cjs exports path mapping:

tslib/package.json

Lines 35 to 36 in 71887cc

	"./tslib.js": "./tslib.cjs",
	"./tslib": "./tslib.cjs",

[vikerman]

Changing the file extension from .js to .cjs is still a breaking change since conditional exports are used only by node and not other tools(and older node).

[ExE-Boss]

That’s why I wanted to get this into v2.0.

[vikerman]

Ok - I shouldn't say breaking change. This change could break the usage of tslib with bundlers and other tools because of the .cjs file extension. Using .mjs for the conditional export would be a safer change.

[guybedford]

Changing file names etc might be considered a breaking change? #121 would be fully backwards compatible I believe.

[orta]

Thanks - ES Module support was shipped with #126