TypeScript 2.7 support

TypeScript 2.7 is coming out in January. We need to get it supported within the v6 timeframe.

build: upgrade to TypeScript 2.7 #22097 ensure that we can compile our codebase with 2.7
make the compiler compatible with 2.7
retain support for TypeScript 2.6 to make g3 upgrade easier

Until now, when Angular supported a new version of TypeScript, it supported it in strict mode.

But in TS 2.7, --strictPropertyInitialization causes a lot of mess in Angular code, as reported in microsoft/TypeScript#20740. Solutions have been discussed, but nothing seems to be included in the 2.7 release.

What's the plans about that ?

Thanks Cyrille, we'll discuss this issue.

…

On Tue, Jan 23, 2018 at 12:40 AM Cyrille Tuzi ***@***.***> wrote: Until now, when Angular supported a new version of TypeScript, it supported it in strict mode. But in TS 2.7, --strictPropertyInitialization causes a lot of mess in Angular code, as reported in microsoft/TypeScript#20740 <microsoft/TypeScript#20740>. Solutions have been discussed, but nothing seems to be included in the 2.7 release. What's the plans about that ? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#21571 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AANM6N8mOkEOMaQUh_AFE0dT4R9CGc0Tks5tNZsSgaJpZM4RgeFi> .

@mhevery

I discussed the --strictPropertyInitialization flag with @mhevery, considered various options, and came to a conclusion that the flag does the right thing and any kind of special treatment for Angular's @Input fields would be compromising the type model.

Our recommendation is to either don't use the flag, or the better option is to initialize the inputs to a default value or null (which requires | null type union).

@IgorMinar

@IgorMinar

Why can not inputs be defined in the constructor? Like this for example :

@Component({ selector: 'my-component' })
class MyComponent {
    constructor(@Input() private myInput: string) {}
}

This would enable a proper use of --strictPropertyInitialization. I understood from documentation about ngOnInit that this may be needed for change detection but I do not understand why change detection need to be started before all inputs are available.

Inputs by definition can change over time. Constructor can only receive one value. But you can use @Attribute in the constructor. Unfortunately someone needs to wire the docs: https://angular.io/api/core/Attribute :-( See spec instead: https://github.com/angular/angular/blob/master/packages/core/test/linker/integration_spec.ts#L2253-L2265 https://github.com/angular/angular/blob/master/packages/core/test/linker/integration_spec.ts#L1252-L1263

Setting a default value is not possible for objects, which is a very common case. Setting to null does not only require to set the | null union type, it also forces to add conditions checking if it's null or not for every bit of code using that data. So it's clearly not an option, especially when it's not relevant.

The very classic architecture of Angular is : a controller component get data via a service and pass the data to a presentation component with @Input(). Check is done in the controller component with *ngIf, so we know the @Input() won't be null, and it would be crazy to add conditions checking everywhere just because of TS behavior.

So for me, it's sure it will be the option of not being strict, which is sad. I think it's really weird TS introduced a feature which is not relevant/friendly with one of the bigger project using it (and I suppose Angular won't be the only affected framework/library). As I said in the other discussion, the current logic is "let's the developer change all his/her code (even when it's good code) to manage the problems", when it should be "let's TypeScript manage its own problems".

@mhevery

@mhevery @Attribute seems interesting in some situations, thanks :)

Actually, I would have hoped that this (@Input on parameter property) :

@Component({ selector: 'my-component' })
class MyComponent {
    constructor(@Input('myInput') public myInput: string) {}
}

would be the equivalent to this in some way :

@Component({ selector: 'my-component' })
class MyComponent {
    @Input('myInput')
    public myInput: string;
    constructor(@Attribute('myInput') myInput: string) {
        this.myInput = myInput;
    }
}

@cyrilletuzi

@cyrilletuzi - I don't think that any check forces you to set the input parameters, so technically marking them as potentially undefined does make sense. I'd rather want to have a possibility within angular to say - these properties need to be set, to have the type check there. The example above, by @nicolashenry would be perfect, if it works like that.

By the way - in case I don't care for implementing a setter for myInput couldn't I directly write

@Component({ selector: 'my-component' })
class MyComponent {
    constructor(@Attribute('myInput') @Input('myInput') public myInput: string) { }
}

@cyrilletuzi

@cyrilletuzi Nothing forces @Input() to be set. A user of the your component may simply chose not to bind to that input in which case your @Input() is not initialize and you should have checks for non-initialized case. I know we disagree, but I think this is the correct behavior.

What would be nice is to have @Input({required:true}) which would be an error if the user created your component and did not bind to that @Input, but as of yet we don't have such a feature.

Could @Input({required:true}) not be accomplished just using ts somehow? By analyzing the @Input variable type and seeing if undefined is an acceptable type?

What would be really nice is that @Input() is required by default, except there is a default value. Like function parameters in TypeScript and quite any language.

But with the actual behavior, yes, there should be a check, and there is one : the *ngIf on the parent controller. So again, when checks are done and the code is good, it's not normal for the developer to have to add more TS specific code just to please TypeScript.

@cyrilletuzi

@cyrilletuzi The strictPropertyInitialization option cannot be applied to lib, there’s no such information (constructor implementation) exists to perform that check...

@trotyl

@trotyl I've had to make my way to that block of code in CLI before, to explain the Angular -> TypeScript supported versions. It seems to me that ideally this information would be represented canonically somewhere in Angular core (and then referred to by CLI code) as it seems to me this is inevitably a property of Angular itself that would apply even to non-CLI users. Roughly akin to the browser support information.

@kylecordes

Could not agree more, @kylecordes.

To that effect, I know that compiler feature landed somewhere in the road to 6.0 with 3ceee99. My assumption (without having tried it out myself) would be that as long as ngc complains loud enough, the CLI should just stop on its tracks if the TS version is unsupported, and developers can "opt out" to ignore via disableTypeScriptVersionCheck in the angularCompilerOptions.

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.}

Navigation Menu

Repository navigation

TypeScript 2.7 support #21571

22 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

TypeScript 2.7 support #21571

Description

Activity

cyrilletuzi commented on Jan 23, 2018

IgorMinar commented on Jan 23, 2018

IgorMinar commented on Feb 2, 2018

nicolashenry commented on Feb 2, 2018

mhevery commented on Feb 2, 2018

cyrilletuzi commented on Feb 2, 2018

nicolashenry commented on Feb 2, 2018

pgrm commented on Feb 5, 2018

mhevery commented on Feb 5, 2018

jbedard commented on Feb 5, 2018

cyrilletuzi commented on Feb 5, 2018

22 remaining items

trotyl commented on Feb 21, 2018

kylecordes commented on Mar 4, 2018

emilio-martinez commented on Mar 5, 2018

angular-automatic-lock-bot commented on Sep 13, 2019

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions