Angular 9 Upgrade Issue

[Brocco]

🐞 bug report

Affected Package

This is a build error, unsure of which package.

Is this a regression?

No

Description

Attempting to upgrade an Angular 8 (8.2.8) project to version 9 (9.0.0-next.10 cli version is 9.0.0-next.8) is resulting in a build error.

🔬 Minimal Reproduction

NOTE: This is a proprietary application that I am unable to share the code base.

ng update @angular/cli @angular/core --next --force
ng build

🔥 Exception or Error

when building all modules being compiled are esm5
building the module in question it displays: Compiling ion2-calendar : main as commonjs

The resulting error is:

ERROR in Cannot resolve type entity ɵngcc1.CalendarModal to symbol

The repo for the library in question:
https://github.com/hsuanxyz/ion2-calendar

🌍 Your Environment

Angular Version:

Angular CLI: 9.0.0-next.8
Node: 11.6.0
OS: darwin x64
Angular: 9.0.0-next.10
... animations, common, compiler, compiler-cli, core, forms
... language-service, platform-browser, platform-browser-dynamic
... router

Package                           Version
-----------------------------------------------------------
@angular-devkit/architect         0.803.2
@angular-devkit/build-angular     0.900.0-next.8
@angular-devkit/build-optimizer   0.900.0-next.8
@angular-devkit/build-webpack     0.900.0-next.8
@angular-devkit/core              8.3.2
@angular-devkit/schematics        8.3.2
@angular/cdk                      8.2.2
@angular/cli                      9.0.0-next.8
@ngtools/webpack                  9.0.0-next.8
@schematics/angular               8.3.2
@schematics/update                0.900.0-next.8
rxjs                              6.5.3
typescript                        3.5.3
webpack                           4.41.0

Anything else relevant?

[JoostK]

I looked into this just now, there is a bug in how the static interpreter keeps track of module imports. It only keeps the latest seen import path, whereas it should be relative to the initial file.

[alxhub]

@JoostK that's actually how it should work - if we report a bestGuessOwningModule for Reference, it should be the last absolute import that we saw on our way there.

E.g.

import {B} from 'lib-a';

where lib-a does:

export {B} from 'lib-b';

should give back a reference to B with bestGuessOwningModule: 'lib-b', even though the user never explicitly imported lib-b.

Unless I'm misunderstanding the issue?

[JoostK]

@alxhub For absolute module paths that would be the case, the issue here is with relative module specifiers. This is the pattern I observed:

// index.ts
import {SOME_COMPONENTS} from './components/index';

@NgModule({
  declaration: [SOME_COMPONENTS];
})
export class SomeModule {}

// components/index.ts
import {SomeComponent} from './some-component';

export const SOME_COMPONENTS = [SomeComponent];

// components/some-component.ts
@Component({ ... })
export class SomeComponent {}

In the defineNgModule call in index.ts, the reference to SomeComponent is imported from './some-component', whereas it actually lives at './components/some-component'. This looks like a situation that we ought to be able to handle correctly.