refactor: update to tslib 2.0 and move to direct dependencies

[alan-agius4]

Tslib version is bound to the TypeScript version used to compile the library. Thus, we shouldn't list tslib as a peerDependencies. This is because, a user can install libraries which have been compiled with older versions of TypeScript and thus require multiple tslib versions to be installed.

While with TS 3.9, we can still use 1.13.0, this isn't a guarantee that tslib will not be breaking in other major versions or future versions of typescript will need a new helper that will be in version 2. In this case we’d be forced to update to tslib but this would break all libraries in the wild that require tslib 1.x. If we keep relying on peerDeps, since only a single version of the lib can be installed that meets the peerDependency criteria.

This change we also be applied to all community libraries using ng-packagr.

Reference: TOOL-1374 and TOOL-1376

[devversion]

Can you please update the commit message to also contain information about TS 3.9? i.e. how it relates with TypeScript 3.9 and how this change impacts users in terms of backwards compatibility?

My thinking was that we should just provide a tslib version that works with older TypeScript versions too (to help avoiding duplicate versions). If I read microsoft/tslib#109 (comment) correctly, the latest 1.x tslib version should be compatible with TS 3.9 too. Can we please clarify the motivation?

Are we changing this now due to TS 3.9 so that we could theoretically rely on live bindings? or is this just a general change that helps us prevent breaking changes if similar tslib incompatibilities come up?

[alan-agius4]

We are essentially doing this because of the latter point you mentioned. I’ll update the commit message later.

Since in other major versions version there is no guarantee that tslib will not be breaking. For example a helper is removed or signature changed.

[alan-agius4]

Also there might be a case where in future versions of typescript, will need a new helper that will be in version 2. In this case we’d be forced to update to tslib version 2, but this would break all libraries in the wild that require tslib 1.x. If we keep relying on peerDeps since you would need to install a single version of the library. This change we also be applied to all community libraries using ng-packagr.

[alan-agius4]

@devversion, update the commit msg.

[devversion]

Thanks @alan-agius4. That comment is great!

I'm a bit unhappy about the potential tslib duplication that could cause this change in the future, but I'm hoping the CLI will have optimizations / warnings if that is the case?

I think it would be always be a red-flag if multiple (but different) tslib versions are bundled, but clearly it's not inevitable (hence I think a good warning might be still useful).

I'm leaving this to @jelbourn. Change LGTM to me.

[jelbourn]

LGTM

[alan-agius4]

I'm a bit unhappy about the potential tslib duplication that could cause this change in the future, but I'm hoping the CLI will have optimizations / warnings if that is the case? I think it would be always be a red-flag if multiple (but different) tslib versions are bundled, but clearly it's not inevitable (hence I think a good warning might be still useful).

I am happy either, but I actually think that it's perfectly acceptable to have multiple versions of tslib. Displaying a warning in the case, would be in-actionable, because the users cannot take any action, maybe their only action would be to change their dependency or file an issue with the library author to update to the latest version of TypeScript.

In the CLI we did implement deduping logic in webpack. Webpack relies solely on npm/yarn dedupe logic, but that is not enough because same module to be present in multiple places within the node_modules tree. angular/angular-cli@a78d1c3

Currently, there are some libraries out there that use tslib, as direct dependency example RXJS and that makes total sense to me, because RXJS shouldn't need to release a new version that supports TS 3.9, they don't have the constraints that Angular has which is it needs to update due the compiler, LS etc...

Strictly speaking, an Angular 10 application which users TS 3.9, we can consume pure TS libraries which were build with TS 1.0 unless the DTS file has errors.

Also, reading the last comment in microsoft/tslib#109 (comment) I do get the impression that the TS team sees tslib as being a direct dependency.

[devversion]

is perfectly acceptable to have multiple versions of tslib.

Yeah, but there is a difference between perfectly acceptable, and perfect in sense of bundle size. To be clear: I'm not necessarily talking in particular about Angular Material here, as we don't really use any helper in the components.

because the users cannot take any action,

That's not necessarily true. The warning should make people aware, and help them consider updating outdated libraries that depend on old TypeScript helpers.

In the CLI we did implement deduping logic in webpack. Webpack relies solely on npm/yarn dedupe logic, but that is not enough because same module to be present in multiple places within the node_modules tree. angular/angular-cli@a78d1c3

Yeah, I saw that. That is a great addition, but doesn't help with the concrete issue I'm talking about. i.e. two separate required tslib versions.

Currently, there are some libraries out there that use tslib, as direct dependency example RXJS and that makes total sense to me, because RXJS shouldn't need to release a new version that supports TS 3.9, they don't have the constraints that Angular has which is it needs to update due the compiler, LS etc...

To be clear: It also makes sense to me that tslib is an explicit dependency. I never said that this is unreasonable. My point is just that it is super easy to end up with multiple versions that way, and that we could help developers with that, by at printing a warning at least (as an example). These warnings might not be always actionable, but even in those cases they can help with delegating the issue to the library author.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}