IVY: ERROR in Invalid dot property access: undefined dot pathname

Description

After converting existing project to IVY, I get an error message which doesn’t say anything about or where the “bug” is supposed to be.

ng serve --verbose
ERROR in Invalid dot property access: undefined dot pathname
ℹ ｢wdm｣: Failed to compile.

🔬 Minimal Reproduction

I took my existing project, enabled IVY in angularCompilerOptions

🌍 Your Environment

Angular Version:

Angular CLI: 8.0.0-rc.2
Node: 10.15.3
OS: darwin x64
Angular: 8.0.0-rc.2
... animations, cli, common, compiler, compiler-cli, core, forms
... language-service, platform-browser, platform-browser-dynamic
... service-worker

Package                           Version
-----------------------------------------------------------
@angular-devkit/architect         0.800.0-rc.2
@angular-devkit/build-angular     0.800.0-rc.2
@angular-devkit/build-optimizer   0.800.0-rc.2
@angular-devkit/build-webpack     0.800.0-rc.2
@angular-devkit/core              8.0.0-rc.2
@angular-devkit/schematics        8.0.0-rc.2
@angular/cdk                      8.0.0-rc.0
@angular/material                 8.0.0-rc.0
@angular/pwa                      0.13.6
@angular/router                   8.0.0-rc.2
@ngtools/webpack                  8.0.0-rc.2
@schematics/angular               8.0.0-rc.2
@schematics/update                0.800.0-rc.2
rxjs                              6.5.1
typescript                        3.4.5
webpack                           4.30.0

** package.json **

{
  "dependencies": {
    "@angular/animations": "^8.0.0-rc.2",
    "@angular/cdk": "^8.0.0-rc.0",
    "@angular/common": "^8.0.0-rc.2",
    "@angular/compiler": "^8.0.0-rc.2",
    "@angular/core": "^8.0.0-rc.2",
    "@angular/forms": "^8.0.0-rc.2",
    "@angular/material": "^8.0.0-rc.0",
    "@angular/platform-browser": "^8.0.0-rc.2",
    "@angular/platform-browser-dynamic": "^8.0.0-rc.2",
    "@angular/pwa": "^0.13.6",
    "@angular/router": "^8.0.0-rc.2",
    "@angular/service-worker": "^8.0.0-rc.2",
    "@ngrx/effects": "8.0.0-beta.1",
    "@ngrx/entity": "8.0.0-beta.1",
    "@ngrx/router-store": "8.0.0-beta.1",
    "@ngrx/store": "8.0.0-beta.1",
    "@ngrx/store-devtools": "8.0.0-beta.1",
    "@ngx-translate/core": "^11.0.1",
    "@ngx-translate/http-loader": "^4.0.0",
    "bootstrap-4-grid": "^2.4.1",
    "core-js": "^2.6.5",
    "file-saver": "^2.0.1",
    "hammerjs": "^2.0.8",
    "json-server": "^0.14.2",
    "ngrx-store-localstorage": "^7.0.0",
    "ngx-animations": "^2.2.4",
    "ngx-device-detector": "^1.3.5",
    "rxjs": "~6.5.1",
    "tslib": "^1.9.0",
    "zone.js": "~0.8.29"
  },
  "devDependencies": {
    "@angular-devkit/build-angular": "^0.800.0-rc.2",
    "@angular/cli": "^8.0.0-rc.2",
    "@angular/compiler-cli": "^8.0.0-rc.2",
    "@angular/language-service": "^8.0.0-rc.2",
    "@types/file-saver": "^2.0.0",
    "@types/jasmine": "~3.3.9",
    "@types/jasminewd2": "~2.0.6",
    "@types/node": "~11.11.0",
    "codelyzer": "~4.5.0",
    "fs-extra": "^7.0.1",
    "jasmine-core": "~3.3.0",
    "jasmine-spec-reporter": "~4.2.1",
    "karma": "~4.0.1",
    "karma-chrome-launcher": "~2.2.0",
    "karma-coverage-istanbul-reporter": "~2.0.5",
    "karma-jasmine": "~2.0.1",
    "karma-jasmine-html-reporter": "^1.4.0",
    "lite-server": "^2.4.0",
    "protractor": "~5.4.2",
    "tslint": "~5.13.1",
    "typescript": "^3.4.5",
    "webpack-bundle-analyzer": "^3.1.0"
  }
}

[JoostK]

@alan-agius4 Oh yes absolutely, it is not at all a problem that it can’t be disabled, I was just wondering.

@spock123 I forgot to mention yesterday that using useFactory will probably workaround the issue:

export function parseLocaleFromUrl(): string {
  return '/' + (window.location.pathname.split('/')[1] || '');
}

 { provide: APP_BASE_HREF, useFactory: parseLocaleFromUrl }

[JoostK]

@spock123 thanks for investigating and sharing the code snippet!

By the looks of it, this problem is caused because of statically analyzing NgModule metadata to list all lazy routes in the program, a process that the CLI runs to support the loadChildren pattern for lazy modules.

When compiling Ivy code, the compiler itself does not attempt to statically analyze NgModule.providers as there is no need for it to interpret that code, it it just compiled verbatim into the correct location. The lazy listing of routes is however still implemented in the Ivy compiler so we should probably fix it to deal with this scenario.

@alan-agius4 is it possible to disable the listing of lazy routes? I found some code paths in the CLI that disable it based on a compiler option, but that option doesn’t seem to be exposed to users.