After running the control flow migration strict template checking is enforced.

[penfold]

Which @angular/* package(s) are the source of the bug?

core

Is this a regression?

No

Description

I have a legacy app which doesn't have strictTemplates enabled.

I updated to ng 17 and then built the project without error.

I then ran the preview migration script to convert the project to the new flow control.

I'm now getting errors consistent with strictTemplates. (These aren't issues with the migration going wrong.)

e.g.
error TS2339: Property 'YYYYYYY' does not exist on type 'XXXXXX'.

Can I force strictTemplates off again? (my tsconfig is unchanged between the 2 builds).

Please provide a link to a minimal reproduction of the bug

No response

Please provide the exception or error you saw

No response

Please provide the environment you discovered this bug in (run ng version)

Angular CLI: 17.0.1
Node: 18.17.1
Package Manager: npm 9.8.1
OS: win32 x64

Angular: 17.0.3
... animations, common, compiler, compiler-cli, core, forms
... language-service, localize, platform-browser
... platform-browser-dynamic, platform-server, router

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1700.1
@angular-devkit/build-angular   17.0.1
@angular-devkit/core            17.0.1
@angular-devkit/schematics      17.0.1
@angular/cli                    17.0.1
@angular/ssr                    17.0.1
@angular/youtube-player         17.0.0
@schematics/angular             17.0.1
rxjs                            7.8.1
typescript                      5.2.2
zone.js                         0.14.2

Anything else?

No response

[penfold]

To limit this down...

As soon as the new flow control is used in that template, then strictTemplates are enforced. Other 'non-strict' templates using the old flow control don't trigger strict errors.

[JoostK]

This was discussed in the team today, and the new control flow will not adopt a mode where it disables type-narrowing capabilities and type-checking of its template block. If this poses a problem for your project then continuing to use ngIf is the way to go, until type-check errors have been resolved. Documentation on this matter will be improved to surface this aspect as a consideration for the control-flow migration.

[penfold]

Ouch! I can see your perspective (and I assume there are some technical details hidden away in your choice). But this is going to bite a lot of people and take the shine off things.

I do have some follow-up questions/suggestions?

• If a project (or nested tsconfig) has strictTemplates:false then add a warning/checkpoint to the migration script.
• Have an option to not migrate subfolders who's tsconfig is set to strictTemplates:false
• In the future (sorry, star gazing), do you envisage a point where if just one component uses the new control flow then all of the project will have the strictTemplate checks active - if so, this will be nail in the coffin for my project (running 7 years from NG 1.08 with all the highs and lows along the way).

I do love the new flow control and strictTemplates! It's just that we have been on a journey from a place where these didn't exist.

[alxhub]

Another option we're considering is to have the migration add $any casts when strictTemplates isn't enabled:

@if ($any(cond)) {
  ...
}

This is how you would opt out of strictTemplates for a particular if block.

In the future (sorry, star gazing), do you envisage a point where if just one component uses the new control flow then all of the project will have the strictTemplate checks active

Control flow will function fine with strictTemplates off, it's just more type-safe than *ngIf which might result in type errors being reported where they weren't before. You can always use a $any cast for a problematic check if the code in question is not ready for such checks.

Eventually we do plan to make strictTemplates the only mode of building Angular (essentially deprecating and removing the strictTemplates: false mode).

[Harpush]

This is quite a problem especially as we don't have a good solution for #49161

[melkorCBA]

This was discussed in the team today, and the new control flow will not adopt a mode where it disables type-narrowing capabilities and type-checking of its template block. If this poses a problem for your project then continuing to use ngIf is the way to go, until type-check errors have been resolved. Documentation on this matter will be improved to surface this aspect as a consideration for the control-flow migration.

So Help me understand this, will you? 😊.

In the basic mode where strictTemplates is not enabled, it doesn't check embedded views, such as *ngIf, *ngFor, other <ng-template>. But for new control flows, it does.

[JoostK]

So Help me understand this, will you? 😊.

In the basic mode where strictTemplates is not enabled, it doesn't check embedded views, such as *ngIf, *ngFor, other <ng-template>. But for new control flows, it does.

Indeed, this is correct.

[pkozlowski-opensource]

After re-discussing it internally with @alxhub and @JoostK we've decided to address this bug. While we really want to push people towards adopting strict template checks, we don't want to block adoption of the new control flow.

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