microsoft-authentication-library-for-js: [MSAL for Angular] Fails to compile with the Ivy

I’m submitting a…

[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report
[ ] Performance issue
[ ] Feature request
[ ] Documentation issue or request
[ ] Other... Please describe:

Library version

Library version: "@azure/msal-angular": "0.1.2"
Angular version: 8.1.1

Current behavior

Build fails with

ERROR in Attempted to get members of a non-class: "export class MsalConfig {
    constructor() {
        this.authority = "";
        this.validateAuthority = true;
        this.cacheLocation = "sessionStorage";
        this.loadFrameTimeout = 6000;
        this.navigateToLoginRequestUrl = true;

Expected behavior

No error

Minimal reproduction of the problem with instructions

Follow the steps here and run ng serve

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 9
  • Comments: 26 (11 by maintainers)

Most upvoted comments

We are working to upgrade @azure/msal-angular to be compatible with latest version of Angular, include Ivy. We’ll update this issue when we have an preview version you can try. Thanks!

Any particular reason MsalService isn’t provided in root?

I’m not sure, I’ll look into that.

ModuleWithProviders is deprecated

Good to know.

Lastly it would be nice if the typescript source files where published.

I’ll see about including them, hopefully just a setting in ng-packagr.


  1. Gotya.
  2. No worries!
  3. I see…at this point I would just create your own client id in your tenant, might just be a result of that client id being created in the MSFT tenant.

GA: we’re working to have it ready for the end of this month, unfortunately, things keep getting pushed back due in part to some dependencies outside our team. Sorry for the delay on that. I’ll have the roadmap updated and we’ll let you know when we have a solid date.

@jasonnutter It works! 🚀


Any particular reason MsalService isn’t provided in root? If it’s provided in root we don’t have to provide it our self. Like it’s done in the sample

ModuleWithProviders is deprecated (see in favor of ModuleWithProviders<MsalModule>

The demo app manually provides MSAL_CONFIG and MSAL_CONFIG_ANGULAR. That’s fine.

However I find it easier just use forRoot like so MsalModule.forRoot(environment.msalConfig, environment.msalAngularConfig) then the MsalModule will setup the providers.

Lastly it would be nice if the typescript source files where published. Cause if I in vscode goto definition of MsalModule I get this

import { ModuleWithProviders } from "@angular/core";
import { Configuration } from "msal";
import { MsalAngularConfiguration } from "./msal-angular.configuration";
import * as ɵngcc0 from '@angular/core';
import * as ɵngcc1 from '@angular/common';
export declare class MsalModule {
    static forRoot(config: Configuration, angularConfig?: MsalAngularConfiguration): ModuleWithProviders<MsalModule>;
    static ɵmod: ɵngcc0.ɵɵNgModuleDefWithMeta<MsalModule, never, [typeof ɵngcc1.CommonModule], never>;
    static ɵinj: ɵngcc0.ɵɵInjectorDef<MsalModule>;

I expected this

@jasonnutter thanks a lot! Now it also works for us with Ivy.

For us, without changes, seems to work also. Can’t test a lot because we have other libraries not compatible with ng9 yet so we’ll not take it into prod.

@jasonnutter we’ve had a chance to try the new beta with our main.ts approach and it’s working!

thank you very much!

@jasonnutter I haven’t had a chance to update our implementation to use the new beta, but the commit you’ve linked to above follows the very same approach as what we were doing.

The only slight difference is that we’re setting some of the values programmatically, like the popup, for the handling of IE, but I would assume that should work ok.

I’m hoping to have a chance tomorrow to look into it.

@willyt150 Can you checkout this commit (which is based on the Angular 9 sample) and let me know if doing something like that works for your app?


  1. MSAL_CONFIG, MSAL_CONFIG_ANGULAR: I agree, and am planning to make them available from the main export of the library.
  2. MsalGuard broadcasts: The difference with the MsalGuard broadcast is that it is broadcasting login-related events, whereas the MsalService broadcasts token-related events. It does look like both would occur, which I agree is potentially confusing (both conceptually and functionally).
  3. Scopes, extraqueryparameters: Those configuration values are meant for the MsalGuard, which I realize isn’t immediately clear from the naming. That is good feedback, and something we can consider.
  4. acquireTokenSilent will first check if there is a cached token, and then only make a round-trip to the network if a new token is needed.

Appreciate the feedback!

I’m facing the exact same issue. Msal-Angular is the only dependency in my project preventing me from using Ivy.