Angular 9 support

[maxokorokov]

• migrate to Angular 9 (Update dependencies for Angular 9 #3447)
• migrate to Bootstrap 4.4.1 (build: add dependency on Bootstrap 4.4.1 #3596)
• update documentation on version support (docs: update minimal supported Angular and Bootstrap versions for v6 #3597)
• do the rc.0 release
• update docs/deps about @angular/localize (docs: add info about '@angular/localize' #3613)
• deprecate Tabset (code + add overview) (docs(tabset): deprecate NgbTabset component #3610)
• deprecate (select) in datepicker (code) (docs(datepicker): deprecate '(select)' output #3611)
• do the 6.0.0 release
• close ivy-related issues

---

Update: published 6.0.0-rc.0, final version should be coming next week

[Zwergenpunk]

Do you have any timeline for support of ng 9?

[maxokorokov]

@Zwergenpunk, rc should be released later this week.

Though we're not aware of any issues with ivy support at the moment, and there are no actual component code changes planned for 6.0.0. So even the latest 5.2.x should work with ivy and NG 9 (despite installation/dependency warnings of course).

[Zwergenpunk]

Thanks for the info and your work :)

[bcmedeiros]

I'm using Angular 9 since release, no issues so far. If you need any tests, I might be able to help, just let me know.

[ghost]

Hello. With enabled Ivy, Angular requires to install @angular/localize because of some module in ng-boostrap. I don't use i18n in my application and want to decrease bundle size as much as possible. Is it possible to avoid importing @angular/localize?

Used ng-bootstrap modules in my app: NgbDropdownModule, NgbPopoverModule, NgbCollapseModule, NgbTooltipModule, NgbModalModule

[maxokorokov]

@nseni, we haven't updated the docs/release notes yet, but there are indeed 2 new peer dependencies:

• tslib → it was a dependency before, we just followed Angular here → Tslib as peerDependency angular/angular#32167
• @angular/localize, because we're using Angular i18n in the library. And it is one of the breaking changes for ivy.

So you're actually kind of using i18n... via ng-bootstrap, because all our labels are translated with i18n. You can read more here → https://angular.io/guide/migration-localize

---

I'm not 100% sure how i18n is supposed to work with ivy and haven't really been following this, but if I understand correctly, it works this way (@pkozlowski-opensource, please correct me if I'm wrong):

Let's take our alert as an example.

1. We have an aria-label="Close" i18n-aria-label="@@ngb.alert.close" somewhere in our ng-bootstrap alert template. And component templates are just strings when ng-bootstrap is distributed as a view engine (not ivy) library (look into your node_modules/@ng-bootstrap/...).
2. When you serve/test/build your app, ng-bootstrap goes through ivy ngcc (result ends up in node_modules/@ng-bootstrap/.../__ivy__ngcc) and our label in the template gets compiled to:

var I18N_1;
if (typeof ngI18nClosureMode !== "undefined" && ngI18nClosureMode) {
    const MSG_EXTERNAL_ngb_alert_close$$FESM2015_NG_BOOTSTRAP_JS__2 = goog.getMsg("Close");
    I18N_1 = MSG_EXTERNAL_ngb_alert_close$$FESM2015_NG_BOOTSTRAP_JS__2;
}
else {
    I18N_1 = $localize `:@@ngb.alert.close␟f4e529ae5ffd73001d1ff4bbdeeb0a72e342e5c8␟7819314041543176992:Close`;
}
const _c3 = ["aria-label", I18N_1];

So you have this global $localize function now.

3. If you look at this $localize function in source code, you'll see that there are 3 possible scenarios to what happens with this function.

For example, if you just ng build --prod your app, you'll end up with this $localize function in polyfills:

Roughly this:

    "N/DB": function(e, t) {
        const n = "undefined" != typeof globalThis && globalThis
          , o = "undefined" != typeof window && window
          , r = "undefined" != typeof self && "undefined" != typeof WorkerGlobalScope && self instanceof WorkerGlobalScope && self
          , s = "undefined" != typeof global && global
          , a = function(e, ...t) {
            if (a.translate) {
                const n = a.translate(e, t);
                e = n[0],
                t = n[1]
            }
            let n = i(e[0], e.raw[0]);
            for (let o = 1; o < e.length; o++)
                n += t[o - 1] + i(e[o], e.raw[o]);
            return n
        };
        function i(e, t) {
            return ":" === t.charAt(0) ? e.substring(function(e, t) {
                for (let n = 1, o = 1; n < e.length; n++,
                o++)
                    if ("\\" === t[o])
                        o++;
                    else if (":" === e[n])
                        return n;
                throw new Error(`Unterminated $localize metadata block in "${t}".`)
            }(e, t) + 1) : e
        }
        (n || s || o || r).$localize = a
    },

And the actual code where this aria-label is set, would look like this:

const uu = ["aria-label", $localize`:@@ngb.alert.close␟f4e529ae5ffd73001d1ff4bbdeeb0a72e342e5c8␟7819314041543176992:Close`];

So "almost" no overhead here, I wouldn't worry about it.

However if you ng build --prod --localize, this $localize function will be compiled out completely and you'll end up with:

const Uc = ["aria-label", "Close"];

But you'll have to mange locales for your app.

I'm not sure, if it is possible to inline these i18n strings any other way and completely avoid overhead.

But hey, you'll get dynamic i18n if necessary now :)

[stevethemacguy]

I'm having a change detection issue with the datepicker when building with IVY. I will submit an issue with a minimal repo on Monday, but just wanted to give a heads-up. If I dynamically add a class to a custom dayTemplate, the class is not added in the HTML until I trigger change detection on the datepicker in some other way (e.g. by hovering over the calendar). Might be related to #3257 and #3438.

[maxokorokov]

@stevethemacguy please do open an issue with the reproduction scenario. Please add the Stackblitz (even though they use view engine, and not ivy at the moment)

EDIT: for ivy you could also use https://ng-run.com/

[maxokorokov]

Closing as 6.0.0 was released, please open new issues if necessary.

[stevethemacguy]

@maxokorokov Unfortunately 6.0.0 didn't fix my issue, but thanks for the ng-run link. I'll see if I can reproduce.

[stevethemacguy]

@maxokorokov Is there a way to share the ng-run project? I have a StackBlitz version done too, but I'm curious. Thank you.

[stevethemacguy]

I confirmed that Angular version 9.1.5 fixed my datepicker change detection issue when building with IVY. (see angular/angular#35400).