Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Installing/updating TypeScript 3.2 with CLI 7.2 is a breaking change #13323

Closed
cyrilletuzi opened this issue Dec 28, 2018 · 8 comments
Closed

Comments

@cyrilletuzi
Copy link
Contributor

cyrilletuzi commented Dec 28, 2018

Bug Report

- [x] bug report

Command

- [x] new

Versions

CLI v7.2.0-rc.0

Repro steps

ng new demoapp

The log given by the failure

Install TS 3.2, due to #13226

Desired functionality

Should continue to install TS 3.1.

Mention any other details that might be useful

Angular 7.0 and 7.1 supported TypeScript 3.1 only. Angular 7.2 now supports TypeScript 3.1 and TypeScript 3.2.

But installing TypeScript 3.2 directly is a breaking change, as it means a higher TypeScript version is required for the whole project.

Why? Because Angular 7.2 may support TS 3.2, but any real-world app will also rely on third-party libraries that may not be compatible with TS 3.2 yet, or even that can't be compatible with TS 3.2 (example: one my lib is affected by a regression in TS 3.2).

This is why Angular will only requires TS 3.2 (or newer) in the next major version, but still supports TS 3.1 in minor versions.

This is also confirmed by the CLI code itself which says here:

// These versions should be kept up to date with latest Angular peer dependencies.

But Angular 7.2 peerDependencies is not TypeScript ~3.2.2, it's >=3.1.1 <3.3 (see here).

So the CLI may use the latest supported TS 3.2 internally, but should not install the latest one in the project.

@alan-agius4
Copy link
Collaborator

It's breaking because of a regression in TypeScript which really this could happen with any package as newer versions might contain regressions, As an example when installing Angular 7.2.0 certain functionality which previously worked with Angular 7.1.0 might break due to newly introduced bug.

While indeed Angular Compiler still supports TypeScript 3.1.1+, we do feel that when generating new projects we should use the latest versions of dependencies so that users can benefit from the latest features.

@cyrilletuzi
Copy link
Contributor Author

cyrilletuzi commented Dec 28, 2018

As mentioned, problems are not only when there are unexpected regressions, it's also:

  • when any third party lib (ngx-translate, ngrx, and so on) is not yet updated to support TS 3.2 (and it should not be a requirement for them to be updated, otherwise it's indeed a breaking change)
  • TypeScript is a special case as it's known to not really follow semver and having breaking changes in minor versions, especially in the recommended strict mode (that's why Angular itself only supports specific minor versions, as with each new TS minor versions Angular has changes to do in its codebase, and so have Angular librairies)

@cyrilletuzi cyrilletuzi changed the title Installing TypeScript 3.2 with CLI 7.2 is a breaking change Installing/updating TypeScript 3.2 with CLI 7.2 is a breaking change Dec 28, 2018
@cyrilletuzi
Copy link
Contributor Author

cyrilletuzi commented Dec 28, 2018

Also, ng update updates to TS 3.2, so it's not affecting new projects only, it can break existing projects.

@alan-agius4
Copy link
Collaborator

TypeScript breaking changes usually effect it's API and the building process of the a library/package not the consumption of it. One of the reasons why Angular itself only supports specific minor versions because Angular Compiler, Build Optimizer, ngtools among others are heavily dependent on TypeScript API.

The public API of a library (DTS) should not change if it was build using TypeScript 2.9, 3.1, 3.2 unless the library author exposes publicly something which was not previously supported (For example a new TypeScript keyword). One can use a library that was built with TypeScript 2.7, in an application that was built using TypeScript 3.2.

@cyrilletuzi
Copy link
Contributor Author

From my experience and what I've also seen in Angular code, TS breaking changes are also often due to details in inference. And this has impacts in the consumption of libs, like the example I gave in the first message.

But that's just my feedback, decision is yours.

@alan-agius4
Copy link
Collaborator

alan-agius4 commented Dec 28, 2018

The problem described here, it's even caused by a library not being built with TypeScript 3.2, as if build your library with TypeScript 3.2, it will still build (If you solely export the type in question), but still it couldn't be used in a TypeScript 3.2 application anyways due the regression from TypeScript (microsoft/TypeScript#29168).

In general TypeScript generated APIs (dts) are compatible together, on of the biggest cases is @types/. It's rare to install a package using the same version of TypeScript you have installed locally, ie @types/node@ts3.1 instead of @types/node@latest.

Similarly when we did upgrade to TypeScript 3.2, we need force our direct dependencies to builds their libraries and publish using the same version.

That said, I am looping in @alexeagle and @IgorMinar to see also their stand.

@alan-agius4
Copy link
Collaborator

We just had a short chat around this internally.

What we concluded is that in general type definitions generated with TypeScript <3.2 will work with >=3.2. In this particular case, type definitions generated with TypeScript 3.2 won't work with the same version. Hence the TypeScript regression.

We try to use the latest version of dependencies for various reasons: use new features, performance improvements and bug fixes.

While indeed the Compiler supports TypeScript 3.1, we always try to use the maximum version supported as opposed to the minimum.

@angular-automatic-lock-bot
Copy link

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.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 9, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants