{"id":25748,"date":"2024-05-10T22:58:56","date_gmt":"2024-05-10T20:58:56","guid":{"rendered":"https:\/\/www.angulararchitects.io\/blog\/angular-17-update-control-flow-app-builder-migration\/"},"modified":"2025-04-06T08:53:20","modified_gmt":"2025-04-06T06:53:20","slug":"angular-17-update","status":"publish","type":"post","link":"https:\/\/www.angulararchitects.io\/en\/blog\/angular-17-update\/","title":{"rendered":"Angular 17 Update: Control Flow & App Builder Migration"},"content":{"rendered":"

Since Angular 18<\/em> is around the corner (planned for the Week of May 20, 2024<\/a>), it's now time to actually update to Angular 17<\/em> in production.<\/p>\n

Besides the automatic update process executed mainly by Angular's fantastic CLI, we also need to take care of 3rd party dependencies<\/strong>, the new control flow migration<\/strong> and eventually switch to the new application builder<\/strong> using esbuild and Vite.<\/p>\n

When to update Angular<\/h2>\n

Manfred and I generally recommend updating after<\/strong> the first or even the second minor release V[N].1.0<\/strong> and before<\/strong> the next major release V[N+1].0.0<\/strong>.<\/p>\n

The reason for waiting up to the second minor is mainly to allow 3rd party libraries to catch up and provide compatible versions of their packages. Most of them will try to catch up earlier \u2013 however, just to make sure everything is well tested and stable for production use.<\/p>\n

In case of the Angular 17<\/em> update, the recommended update window is between V17.2.0<\/em> (February 14, 2024) and V18.0.0<\/em> (planned for the week of May 20, 2024). So, it's about time to update \ud83d\ude0a<\/p>\n

Doing an Angular update<\/h2>\n

Using the Angular CLI<\/h3>\n

In my experience, Angular updates are usually quite smooth and straightforward. The Angular CLI<\/em> provides a fantastic tool to automate the update process. You can run the following command to update your project to Angular 17<\/em>:<\/p>\n

ng update @angular\/core@17 @angular\/cli@17<\/code><\/pre>\n
Depending on your project setup, you might want to include some additional packages like code>@angular\/material<\/code<\/a> and code>@angular\/cdk<\/code<\/a> or code>@angular-eslint\/schematics<\/code<\/a>:<\/p>\n
ng update @angular\/core@17 @angular\/cli@17 @angular\/material@17 @angular\/cdk@17 @angular-eslint\/schematics@17<\/code><\/pre>\n
If you're using Nrwl Nx<\/code>, you can simply run:<\/p>\n
nx migrate latest<\/code><\/pre>\n
As already mentioned, these Angular core updates typically are very smooth. If something needs to be changed in your codebase or configuration, the CLI<\/em> will do it automatically or \u2013 if that's not possible \u2013 tell you what to do and provide you with the necessary information.<\/p>\n
By the way, it's officially planned to use AI in the Angular CLI<\/em> in the future to make the automated update process even smoother \ud83e\udd2f<\/p>\n
Manually updating 3rd party packages<\/h3>\n
However, you need to be aware that the CLI can't and doesn't update everything<\/strong>. Since most Angular Apps use 3rd party dependencies, you need to check if they have a compatible version for Angular 17<\/em>. If yes, you must update them too. If they are not Angular specific you should update them as well to get the latest features, bug fixes and - most importantly - security updates. In any case, you should avoid peer dependency conflicts<\/strong>.<\/p>\n
Here is an example of how you can update packages manually. First, check for outstanding updates:<\/p>\n
npm outdated<\/code><\/pre>\n
Then update the mentioned packages. I typically use my favorite IDE, Intellij WebStorm, to find the latest version: Simply open your package.json<\/code> and your IDE will show you the latest version of the package when editing the version. When done updating the dependencies, run:<\/p>\n
npm i | yarn | pnpm i<\/code><\/pre>\n
Important notes on updating 3rd party packages<\/h3>\n
    \n
  1. If you're using Component Frameworks from Bootstrap<\/code> to Angular Material<\/code>, watch out for breaking changes<\/strong> that need your attention.<\/li>\n
  2. If you're running multiple frontend projects on your machine, make sure to try pnpm<\/a><\/strong> for faster installs and much, much less disk space consumption \ud83c\udf89<\/li>\n
  3. Make sure to avoid peer dependency conflicts<\/strong> as good as possible. For example, you won't be able to use the latest eslint<\/code> version 9.X.X because @angular-eslint<\/code> currently only supports version 8.X.X. So you'd currently prefer eslint<\/code> version 8.57.0 until @angular-eslint<\/code> catches up (probably in Version 18, but who knows). In some cases however, we will have to use npm i --legacy-peer-deps<\/code> and with that potentially screw up our dependency resolution \u2013 so be careful with that!<\/li>\n
  4. Final advice on doing an update across multiple Angular versions<\/strong>: Do one version after the other and test everything in between. This way you can easily identify potential breaking changes and fix them step by step. For example, Angular 16<\/em> has dropped support for ViewEngine<\/code> libraries, so you need to make sure that all your dependencies are already supporting Ivy<\/code>. If not, you need to update them first. In some rare cases, you might even need to replace those dependencies. At least that's what I did in my projects.<\/li>\n<\/ol>\n
    Now let's assume you've successfully updated your project to Angular 17<\/em> and all your 3rd party dependencies (except the ones like eslint<\/code>) are as well up-to-date. Let's move on to the next migration step.<\/p>\n
    New control flow migration<\/h2>\n
    Angular 17<\/em> ships with its new template control flow syntax<\/a>. The Angular team wanted to improve the framework performance<\/strong> and also the developer experience<\/strong>. At first glance the new syntax looked a bit awkward (like PHP) to me, I must confess. However, you'll get used to it pretty fast. The handling of code>@for<\/code<\/a> loops during runtime is up to 90% faster according to independent benchmarks<\/a>:<\/p>\n
    \"Angular<\/p>\n
    Running the migration schematic<\/h3>\n
    The Angular CLI<\/em> doesn't automatically migrate your project. To migrate your Angular HTML templates to the new control flow syntax, you can use this Angular CLI<\/code> schematic:<\/p>\n
    ng g @angular\/core:control-flow<\/code><\/pre>\n
    Manual improvements & clean up<\/h3>\n
    While the migration schematic hopefully (and in my experience actually) doesn't produce any errors or bugs, you might want to improve and clean up your code manually afterward.<\/p>\n
    Here is some general advice<\/strong> on the new control flow:<\/p>\n
      \n
    1. Check your @if<\/code> blocks. You might want to reduce complexity here and there by using the @else if<\/code> and @else<\/code>. This will make your HTML templates more readable and thus more maintainable.<\/li>\n
    2. Check your @for<\/code> blocks. You might want to add the @empty<\/code> block \u2013 again cleaning up your HTML templates. Also, make sure you're using the now mandatory track<\/code> intelligently.<\/li>\n
    3. Enforce the new control flow syntax in your team. You might want to add the corresponding @angular-eslint<\/code> rule to your eslint<\/code> configuration:\n
      \"files\": [\"*.html\"],\n\"rules\": {\n \"@angular-eslint\/template\/prefer-control-flow\": \"warn\",<\/code><\/pre>\n<\/li>\n
    4. Since you're now using the new control flow syntax, think about introducing @defer<\/code> blocks for heavyweight components in your app.<\/li>\n<\/ol>\n
      Adding @defer for lazy-loading of components<\/h3>\n
      To learn how to use code>@defer<\/code<\/a>, check out my blog post Angular 17\u2019s Deferrable Views<\/a>. Make sure to use code>@defer<\/code<\/a> especially for large dependencies: How to lazy load large 3rd-party deps with Angular 17\u2019s @defer<\/a>.<\/p>\n
      Now let's assume you've successfully migrated your HTML templates. Let's move on to the final migration step.<\/p>\n
      Application builder migration<\/h2>\n
      Angular 16<\/em> introduced the new application builder<\/a> \u2013 using modern tools esbuild and Vite \u2013 which has now become the default builder for new projects in Angular 17<\/em>. If you haven't switched to the new builder yet, you should try it now. It is definitely faster and also said-to-be more reliable than the old one, and it even results in a slightly smaller build size \ud83d\ude0e<\/p>\n
      To switch existing Angular apps to the new builder, you need to run the update script or edit your angular.json<\/code> (or project.json<\/code> for Nx projects).<\/p>\n
      Changing the app builders automatically<\/h3>\n
      Run this special update script to update all app builders automatically:<\/p>\n
      ng update @angular\/cli --name use-application-builder<\/code><\/pre>\n
      Changing the app builder in angular.json<\/h3>\n
      In your angular.json<\/code>, you would typically find:<\/p>\n
      "architect": {\n  "build": {\n    "builder": "@angular-devkit\/build-angular:browser",<\/code><\/pre>\n
      Changing the builder field is the first change you will need to make:<\/p>\n
      "architect": {\n  "build": {\n    "builder": "@angular-devkit\/build-angular:application",<\/code><\/pre>\n
      Additionally, you need to rename main<\/code> to browser<\/code> within the build target. Here is a table of changes copied from the Angular Docs<\/a> on esbuild:<\/p>\n
      \"esbuild\"<\/p>\n
      If you're using SSR make sure to change the builder in the server<\/code> targets as well.<\/p>\n
      Replacing webpack bundle analyzer<\/h3>\n
      Since were not using webpack<\/code> anymore, you need to replace the webpack-bundle-analyzer<\/code> as well. Here are some tools you can use to analyze your Vite bundles:<\/p>\n