Update to Angular Version 8 now!
Tags: angular, webdev, javascript
Published: 2019-08-05 18:37:54

---
title: Update to Angular Version 8 now!
canonical_url: 'https://juristr.com/blog/2019/06/angular-v8'
published: true
description: 'What''s new in Angular v8, how to update and what to watch out for'
cover_image: 'https://juristr.com/blog/assets/imgs/ng-v8-upgrade.jpg'
tags:
  - angular
  - webdev
  - javascript
---

_This post has originally been published on [https://juristr.com/blog/2019/06/angular-v8](https://juristr.com/blog/2019/06/angular-v8). Go to [juristr.com/blog](https://juristr.com/blog) for more content_

---
    


  Let's dive into the latest Angular version 8 that just got released. We'll quickly explore what's new, why you should update, how that works and what you should watch out for.

<!--more-->



Before you start, there's also an official post about the release from the Angular team:

> Check out my related post about "[Lazy Load Angular Components](https://juristr.com/blog/2019/04/state-lazy-loading-components-angular/)"

During the upgrade you will get a notification with a link to more details.
![](https://juristr.com/blog/assets/imgs/querymigration.png)

You can read up all the details at [https://angular.io/guide/static-query-migration](https://angular.io/guide/static-query-migration).

If the Angular CLI is not able to automatically infer whether to use the static or dynamic resolution, it'll add a corresponding comment and warning on the console

![](https://juristr.com/blog/assets/imgs/querymigration-manualwork.png)

**To summarize, what is it all about?**

Assume you have the following:

```html
<div foo></div>
```

In your code you'd use a `@ViewChild` such as

```typescript
@ViewChild(Foo) foo: Foo;
```

_(where `Foo` is some Angular directive)_

Usually it's always safe to assume `foo` will be populated after the `ngAfterViewInit` (or `ngAfterContentInit` for content queries with `@ContentChild`). However, some of them were also accessible already in the `onInit` directly. The reason is that the compiler behind the scenes categories them in

- **static queries** available immediately
- **dynamic queries** available only at runtime

Our code example above would be an example of a **static query** because `<div foo>` it is immediately available. We could safely access it in the `ngOnInit`. On the other side, assume we change the code like

```html
<div foo *ngIf="isVisible"></div>
```

In such case, it would only become available once `isVisible` evaluates to true, which might happen at any time while executing the app. Such queries are **dynamic queries**.

The main problem is that this wasn't explicit. Hence, when upgrading to v8, the code migration will automatically transform your code to 

```typescript
// query results available in ngOnInit
@ViewChild('foo', {static: true}) foo: ElementRef; 

// query results available in ngAfterViewInit
@ViewChild('foo', {static: false}) foo: ElementRef;
```

## TypeScript upgrade

By upgrading to Angular 8 you'll also upgrade to TypeScript 3.4. If you're curious about the new features [here's the corresponding documentation](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-4.html).

As a result after the upgrade (even though that completes successfully), you may get errors. Most probably they are due to better type inference which reveal new potential typing issues.


## Other Deprecations

Check out the [new deprecation guide](https://angular.io/guide/deprecations) on the official site. Still have questions? Open an issue in the [Angular CLI repository](https://github.com/angular/angular-cli) if it's related to the upgrade or on the [Angular repository](https://github.com/angular/angular) if it's framework related. Or simply ping [me on Twitter](https://twitter.com/juristr) :smiley:

## FAQ - Potential upgrade issues

### Rerun migrations

What if you did the Angular upgrade, but for whatever reason some of the code transformations didn't complete successfully. You end up having Angular 8 (or whatever version you're upgrading) already in your node_modules folder and `package.json`.

Generally speaking, my suggestion is to use Git. Create a migration branch, which allows you to easily go back and forth during the upgrade. Commit after each step so you've got a backup on the way.

Other than that, the Angular CLI also gives you the possibility to run the migration again, even though you already have the latest version in your `package.json`. Just execute

```
// re-run CLI schematics
$ ng update @angular/cli --from 7 --to 8 --migrate-only

// re-run Angular core schematics
$ ng update @angular/core --from 7 --to 8 --migrate-only
```

### Material Upgrade: FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

When I upgraded Angular material with `ng update @angular/material` on our fairly large monorepo, I got the following exception.

```
<--- Last few GCs --->

[85884:0x103802200]   712051 ms: Scavenge 2004.6 (2047.9) -> 2004.5 (2047.9) MB, 4.1 / 0.0 ms  (average mu = 0.199, current mu = 0.181) allocation failure
[85884:0x103802200]   712072 ms: Scavenge 2006.3 (2048.9) -> 2004.6 (2048.4) MB, 3.8 / 0.0 ms  (average mu = 0.199, current mu = 0.181) allocation failure
[85884:0x103802200]   712077 ms: Scavenge 2005.6 (2049.4) -> 2005.6 (2049.9) MB, 4.3 / 0.0 ms  (average mu = 0.199, current mu = 0.181) allocation failure


<--- JS stacktrace --->

==== JS stack trace =========================================

    0: ExitFrame [pc: 0x100e146e6]
Security context: 0x08b76239a2f1 <JSObject>
    1: stringSlice(aka stringSlice) [0x8b725f97839] [buffer.js:~568] [pc=0x1d077761a16a](this=0x08b76f0804d1 <undefined>,0x08b765580f19 <Uint8Array map = 0x8b742025759>,0x08b786894e49 <String[#4]: utf8>,0,1073870)
    2: toString [0x8b7623f02f9] [buffer.js:~622] [pc=0x1d0777ee3789](this=0x08b765580f19 <Uint8Array map = 0x8b742025759>,0x08b786894e49 <String[#4]:...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x100075bd5 node::Abort() [/Users/jstrumpflohner/.nvm/versions/node/v12.4.0/bin/node]
 2: 0x100076316 node::errors::TryCatchScope::~TryCatchScope() [/Users/jstrumpflohner/.nvm/versions/node/v12.4.0/bin/node]
 3: 0x1001697d7 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/Users/jstrumpflohner/.nvm/versions/node/v12.4.0/bin/node]
 4: 0x10016976c v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/jstrumpflohner/.nvm/versions/node/v12.4.0/bin/node]
 5: 0x1005480d5 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/Users/jstrumpflohner/.nvm/versions/node/v12.4.0/bin/node]
 6: 0x1005491c3 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [/Users/jstrumpflohner/.nvm/versions/node/v12.4.0/bin/node]
 7: 0x100546bc3 v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/Users/jstrumpflohner/.nvm/versions/node/v12.4.0/bin/node]
 8: 0x10054487f v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/jstrumpflohner/.nvm/versions/node/v12.4.0/bin/node]
 ...
[1]    85884 abort      ng update @angular/material @angular/cdk @angular/cdk-experimental
```

This is a common issue when the node process needs more memory. To solve this, pass the `max_old_space_size` option to the node process, like this:

```
$ node --max_old_space_size=8000 ./node_modules/.bin/ng update @angular/material @angular/cdk
```

### Ngrx: Type 'Observable<AppConfigLoaded>' is not assignable to type 'Observable<Action>'

Another strange error I got when upgrading my NX based monorepo from v7 to v8 was the following:

```
ERROR in libs/r3-core/src/lib/+state/app-config/app-config.effects.ts(22,5): error TS2322: Type '(action: LoadAppConfig, state: AppConfigPartialState) => Observable<AppConfigLoaded>' is not assignable to type '(a: LoadAppConfig, state?: AppConfigPartialState) => void | Action | Observable<Action>'.
  Type 'Observable<AppConfigLoaded>' is not assignable to type 'void | Action | Observable<Action>'.
    Type 'Observable<AppConfigLoaded>' is not assignable to type 'Observable<Action>'.
      Types of property 'source' are incompatible.
        Type 'import("/Users/jstrumpflohner/myapp/node_modules/rxjs/internal/Observable").Observable<any>' is not assignable to type 'import("/Users/jstrumpflohner/myapp/node_modules/@nrwl/angular/node_modules/rxjs/internal/Observable").Observable<any>'.
          Types of property 'operator' are incompatible.
            Type 'import("/Users/jstrumpflohner/myapp/node_modules/rxjs/internal/Operator").Operator<any, any>' is not assignable to type 'import("/Users/jstrumpflohner/myapp/node_modules/@nrwl/angular/node_modules/rxjs/internal/Operator").Operator<any, any>'.
              Types of property 'call' are incompatible.
                Type '(subscriber: import("/Users/jstrumpflohner/myapp/node_modules/rxjs/internal/Subscriber").Subscriber<any>, source: any) => import("/Users/jstrumpflohner/myapp/node_modules/rxjs/internal/types").TeardownLogic' is not assignable to type '(subscriber: import("/Users/jstrumpflohner/myapp/node_modules/@nrwl/angular/node_modules/rxjs/internal/Subscriber").Subscriber<any>, source: any) => import("/Users/jstrumpflohner/myapp/node_modules/@nrwl/angular/node_modules/rxjs/internal/types").TeardownLogic'.
                  Types of parameters 'subscriber' and 'subscriber' are incompatible.
                    Property '_parentOrParents' is missing in type 'Subscriber<any>' but required in type 'Subscriber<any>'.
```

This seems due to an incompatibility between RxJS and Ngrx v7 in a certain version. Upgrading to Ngrx v8 might solve the issue (I didn't try though). In my case downgrading RxJS to `~6.4.0` helped.

```
$ yarn add rxjs@~6.4.0
```

or 

```
$ npm i rxjs@~6.4.0 --save
```