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

feat(core): support TypeScript 4.7 #45749

Closed
wants to merge 1 commit into from
Closed

Conversation

crisbeto
Copy link
Member

@crisbeto crisbeto commented Apr 25, 2022

Adds support for TypeScript 4.7. Changes include:

  • Bumping the TS version as well as some Bazel dependencies to include fix(concatjs): resolve error with TypeScript 4.7 bazelbuild/rules_nodejs#3420.
  • Adding a backwards-compatibility layer for calls to updateTypeParameterDeclaration.
  • Making LView generic in order to make it easier to type the context based on the usage. Currently the context can be 4 different types which coupled with stricter type checking would've required a lot of extra casting all over core.
  • Fixing a bunch of miscellaneous type errors.
  • Removing assertions of ReferenceEntry.isDefinition in a few of the language service tests. The field isn't returned by TS anymore and we weren't using it for anything.
  • Resolving an error in the language service that was caused by TS attempting to parse HTML files when we try to open them. Previous TS was silently setting them as ScriptKind.Unknown and ignoring the errors, but now it throws. I've worked around it by setting them as ScriptKind.JSX.

@crisbeto crisbeto force-pushed the ts-4.7 branch 8 times, most recently from bea8850 to 091beed Compare April 26, 2022 08:16
@crisbeto crisbeto added action: review The PR is still awaiting reviews from at least one requested reviewer area: core Issues related to the framework runtime target: major This PR is targeted for the next major release labels Apr 26, 2022
@ngbot ngbot bot modified the milestone: Backlog Apr 26, 2022
@crisbeto crisbeto added this to the v14-candidates milestone Apr 26, 2022
@crisbeto crisbeto marked this pull request as ready for review April 26, 2022 16:31
Copy link
Member

@JoostK JoostK left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure if the changes to LView are necessary/desirable, but left some comments for your consideration.

packages/compiler-cli/src/ngtsc/typecheck/src/ts_util.ts Outdated Show resolved Hide resolved
packages/compiler-cli/src/ngtsc/typecheck/src/ts_util.ts Outdated Show resolved Hide resolved
packages/core/src/render3/component_ref.ts Outdated Show resolved Hide resolved
packages/core/src/render3/instructions/change_detection.ts Outdated Show resolved Hide resolved
@@ -78,7 +78,7 @@ export interface OpaqueViewState {
* Keeping separate state for each view facilities view insertion / deletion, so we
* don't have to edit the data array based on which views are present.
*/
export interface LView extends Array<any> {
export interface LView<T = unknown> extends Array<any> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you expand on the motivation for these changes, e.g. in the commit message? It's unclear why this has been changed and it has quite a knock-on effect throughout the codebase.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's because LView[CONTEXT] can have 4 different types which made it difficult to deal with when combined with some of the new type checking changes. This saves us some as unknown as <something> casts across the codebase.

@@ -266,8 +266,8 @@ export function ɵɵdisableBindings(): void {
/**
* Return the current `LView`.
*/
export function getLView(): LView {
return instructionState.lFrame.lView;
export function getLView<T>(): LView<T> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's generally a bad idea to have a generic type in an output position only, as it is guaranteed to be unsafe (i.e. the caller can specify any type argument without type-checking against some concrete value). I realise this isn't the first usage of such pattern (there's lots actually!) but it makes the reason why LView has a generic type less effective IMHO.

Copy link
Contributor

@atscott atscott left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

reviewed-for: language-service

@crisbeto
Copy link
Member Author

I've addressed the feedback and expanded the PR description with more info on the changes.

@crisbeto crisbeto requested review from AndrewKushnir and removed request for alxhub April 27, 2022 16:31
Copy link
Member

@josephperrott josephperrott left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM overall though I share some of @JoostK's concerns about the unsafe usage of generics with LView.

An additional question is if we should be landing this with ts as beta or wait until its at least in rc.

@crisbeto
Copy link
Member Author

Due to the feature freeze, we have to land it as a beta and then update to RC during our RC period. The final version should be out before the v14 final release.

@@ -78,7 +78,7 @@ export interface OpaqueViewState {
* Keeping separate state for each view facilities view insertion / deletion, so we
* don't have to edit the data array based on which views are present.
*/
export interface LView extends Array<any> {
export interface LView<T = unknown> extends Array<any> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd propose adding more descriptive generic name:

Suggested change
export interface LView<T = unknown> extends Array<any> {
export interface LView<Context = unknown> extends Array<any> {

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't mind making the change, but it goes against the convention we have everywhere else where we use single-character names for generics.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I personally feel clarity is better than convention in this case.

Copy link
Member

@JoostK JoostK left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I continue to feel uncomfortable with the generic type arg for LView, but I haven't seen what the alternative would look like so can't compare which is better/worse.

package.json Show resolved Hide resolved
packages/core/src/render3/interfaces/view.ts Outdated Show resolved Hide resolved
@crisbeto
Copy link
Member Author

I've addressed the latest feedback. Regarding making LView generic, I did it because I found my self having to cast foo as unknown as Something in a bunch of places so having it be generic made sense. We should also keep in mind that this is an internal API so we can change it at any time if we want to.

Copy link
Contributor

@AndrewKushnir AndrewKushnir left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed-for: public-api

@pullapprove pullapprove bot requested a review from alxhub April 29, 2022 04:45
Copy link
Contributor

@jessicajaniuk jessicajaniuk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

reviewed-for: public-api

@@ -78,7 +78,7 @@ export interface OpaqueViewState {
* Keeping separate state for each view facilities view insertion / deletion, so we
* don't have to edit the data array based on which views are present.
*/
export interface LView extends Array<any> {
export interface LView<T = unknown> extends Array<any> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I personally feel clarity is better than convention in this case.

Adds support for TypeScript 4.7. Changes include:
* Bumping the TS version as well as some Bazel dependencies to include bazelbuild/rules_nodejs#3420.
* Adding a backwards-compatibility layer for calls to `updateTypeParameterDeclaration`.
* Making `LView` generic in order to make it easier to type the context based on the usage. Currently the context can be 4 different types which coupled with stricter type checking would required a lot of extra casting all over `core`.
* Fixing a bunch of miscellaneous type errors.
* Removing assertions of `ReferenceEntry.isDefinition` in a few of the language service tests. The field isn't returned by TS anymore and we weren't using it for anything.
* Resolving in error in the language service that was caused by TS attempting to parse HTML files when we try to open them. Previous TS was silently setting them as `ScriptKind.Unknown` and ignoring the errors, but now it throws. I've worked around it by setting them as `ScriptKind.JSX`.
@crisbeto
Copy link
Member Author

I've pushed an extra integration test which tries to import all our types using the new module resolution option.

Copy link
Member

@jelbourn jelbourn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Reviewed-for: public-api

@crisbeto crisbeto added action: merge The PR is ready for merge by the caretaker and removed action: review The PR is still awaiting reviews from at least one requested reviewer labels Apr 29, 2022
@dylhunn
Copy link
Contributor

dylhunn commented Apr 29, 2022

This PR was merged into the repository by commit 29039fc.

@dylhunn dylhunn closed this in 29039fc Apr 29, 2022
akunzai added a commit to akunzai/angular-boilerplate that referenced this pull request May 25, 2022
- [Angular supports TypeScript 4.7 until v14](angular/angular#45749)
@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 May 30, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
action: merge The PR is ready for merge by the caretaker area: core Issues related to the framework runtime target: major This PR is targeted for the next major release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

9 participants