[Feature Request] Option to compile in the tslib dependency?

[fireflysemantics]

Type of Issue

[ ] Bug Report
[X ] Feature Request

Description

A feature: please describe your use case and motivation

Right now the tslib is added as a direct dependency to Angular Package Format projects.

This means that all consumers of the project have to use a tslib compatible dependency.

It would be great if the required tslib lines of code were compiled in directly into the package (Perhaps as an option) so that consumers of the library don't have to worry about tslib version compatibility.

[alan-agius4]

In general it's not recommended to disable importHelpers as this would cause an increase in bundle size. Also, tslib is a direct dependency of the library and therefore it's not of concern for library consumers.

[fireflysemantics]

Let's take for example a really simple fictional library published on NPM called @fireflysemantics/add:

It only has one simple function add in it and that adds two numbers:

export function add(a:number, b:number) {...}

So on the surface of it all, the Angular Package Format seems like a great way to package up this function for use in all sorts of environments, because the ng-packagr produces all the desirable package formats automatically (UMD, FESM, etc.) so if we use it we get all this built for free.

BUT hold on. It also builds in tslib as a direct dependency. So now if we for example upgrade Angular ... all of a sudden we are getting incompatibility issues and we either have to upgrade the build or just find some other package that adds two numbers that is compatible.

Maybe one that does not use the Angular Package Format ...

And so if someone with a React environment wants to use @fireflysemantics/add and they see the tslib direct dependency ... they may. just pass on it and find something else because they don't need the tslib dependency ...

[alan-agius4]

I think if you are building a “util” library ng-packagr is not the right tool for you.

Using esbuild or rollup directly would be a better choice. Using Ng-packagr for such case would cause a bottleneck, because of the number of formats it needs to generate which might not be needed for your case and also the fact the under the hood it uses the Angular compiler to transform TypeScript, CSS and HTML files which in such cases wouldn’t be needed.

That being said, I think we can be a bit smart and only include the dependency on tslib when it’s actually being used if this can be done efficiently.

[fireflysemantics]

Ideally 2 things would happen.

1. Like you are saying, if the library does not depend on tslib at all then just leave the direct dependency off.
2. If there are segments that do depend on tslib then provide an option to generate in code supporting these at build time such that the library can stand alone without tslib.

It may be that this makes the bundle heavier, but at least now the developer is in control of whether they want to allow this and can make that tradeoff decision themselves ...

This removes guess work. Ideally developers should not have to wonder whether ng-packagr is right.

It's not just that they have to wonder about this. If they decide that it is right, and start producing packages using it, they still have to upgrade these with a new build, whenever the target environment changes the tslib version requirements. This can be a great deal of additional work.

So if they could just package up anything and have confidence that ng-packagr will produce bundles that can be used any just about any environment that would make both the ng-packagr ecosystem and the productivity it affords much more attractive.