AoT Compilation not detecting template error

[josephliccini]

I'm submitting a...

[x ] Regression (a behavior that used to work and stopped working in a new release)
[x ] Bug report  
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

Current behavior

A component has public properties, heroTitle: string, v2Layout: boolean.

In template:

<ng-container *ngIf="v2Layout">
    {{ heroTitle }}
</ng-container>

This works, as expected, no error reported.

I will modify template like so:

<ng-container *ngIf="v2Layout">
    {{ heroTitleeeeee }}
</ng-container>

Now, there is no error reported in the AoT compiler, even if I kill the watcher and do a full rebuild.

Furthermore, if one does this:

<!-- <ng-container *ngIf="v2Layout"> -->
    {{ heroTitleeeeee }}
<!-- </ng-container> -->

We get a compilation error in AoT, both in Full Rebuild and Watcher

I am pretty sure this if happening because of *ngIf but no way to be sure. I have seen this in other parts of our application too. On things like [class.foo]="something" if an *ngIf is above it, the compiler won't catch typos, etc.

Expected behavior

I would expect in each case where I am using {{ heroTitleeeeee }} the AoT compiler fails the build.

Minimal reproduction of the problem with instructions

Above

What is the motivation / use case for changing the behavior?

We'd like our AoT builds to be able to detect these errors so that we don't have typos and other issues on our templates before checking in / testing.

Environment

Windows 10

Angular version: 5.0.1


Browser:
- [ ] Chrome (desktop) version XX
- [ ] Chrome (Android) version XX
- [ ] Chrome (iOS) version XX
- [ ] Firefox version XX
- [ ] Safari (desktop) version XX
- [ ] Safari (iOS) version XX
- [ ] IE version XX
- [ ] Edge version XX
 
For Tooling issues:
- Node version: XX   Node 6.9.1
- Platform:   Windows

Others:

[josephliccini]

Actually I am seeing this on 4.4.4 as well.

Maybe it's related to a TypeScript version? We are using TS 2.4.2

[josephliccini]

Tried TS 2.5.3 and TS 2.6.1, so unlikely it's a TS issue. Maybe I am not configuring a setting correctly or something..

[trotyl]

Can be reproduced in edit.ng directly.

[ionathanch]

I'm seeing this issue for *ngFor as well. I tested it with the following:

In app.component.ts:

import { Component } from '@angular/core';

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.css']
})
export class AppComponent {
  public title: string = "app";

  public bool: boolean = true;
  public variableInsideIf: string = "ngIfTest";

  public list: number[] = [1, 1, 2, 3, 5, 8, 13];
  public variableInsideFor: string = "ngForTest";
}

In app.component.ng.html:

<div style="text-align:center">
  <div>
    {{title}}
  </div>
  <div *ngIf="bool">
    {{variableInsideIf}}
  </div>
  <div *ngFor="let n of list">
    {{variableInsideFor}} {{n}}
  </div>
</div>

If I change {{title}} to {{titleeee}} or {{title.dummy}}, I get the compilation error, but if I change {{variableInsideIf}} to {{variableInsideIffff}} or {{variableInsideFor}} to {{variableInsideForrrr}} or {{n}} to {{n.dummy}} I don't get the error.

I also tried compiling with ngc using @angular/compiler-cli@4.4.6, and this is what I see in the generated app.component.ngfactory.ts:

...
var _co:any = _v.component;
const currVal_0:any = _co.variableInsideIf;
...
var _co:any = _v.component;
const currVal_0:any = _co.variableInsideFor;
const currVal_1:any = _v.context.$implicit;
...
var _co:i3.AppComponent = _v.component;
const currVal_1:any = _co.bool;
const currVal_2:any = _co.list;
...
var _co:i3.AppComponent = _v.component;
const currVal_0:any = _co.title;

As you can see, when accessing title, _co has the correct type annotation of AppComponent, but when accessing variableInsideIf or variableInsideFor, _co has the type annotation of any instead, which is probably why the error isn't being caught on compilation. Additionally, the n inside the for loop corresponds here to _v.context.$implicit, but its type isn't checked anywhere, so changing {{n}} to {{n.dummy}} yields _v.context.$implicit.dummy which doesn't fail but I believe should, since we can trace that n is from list is from AppComponent, and it does fail for title.dummy.

Edit: This angular/angular-cli#5764 might also be related?

[BorntraegerMarc]

@trotyl the provided link doesn't work anymore 😉

[trotyl]

@BorntraegerMarc fixed, just mean it literally.

[mbx-mbx]

Same issue here when using *ngIf.

[mhevery]

This is a know bug which we are working on fixing right now.

Duplicate of #19792

[josephliccini]

Thanks @mhevery !

fwiw with issues like #19792 it might be good to put a brief summary for those outside Google just so we don't duplicate bugs in your bug tracker 😄

[lichunr]

any update on this one? we're still facing this issue, thanks

[vanslly]

@lichunr For some additional template type checking you should set fullTemplateTypeCheck = true in your tsconfig.json: https://angular.io/guide/aot-compiler#fulltemplatetypecheck

Template type checking is still poor, but is improved with Renderer 3 (Ivy). Even with Angular 8 with Renderer 3 you still need to set fullTemplateTypeCheck = true and in the future this will be on by default. Only reason it's not on by default is for backwards compatibility.

[lichunr]

@vanslly Thx for the solution!

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