Prod build fails with "Can't resolve '@angular/material/material'

[SteveHWork]

Bug, feature request, or proposal:

Bug

What is the expected behavior?

ng build --prod should complete without errors.

What is the current behavior?

Prod build fails with:

ERROR in ./app/$$_gendir/app.module.ngfactory.ts
Module not found: Error: Can't resolve '@angular/material/material'
in 'C:\Code\app$$_gendir'
@ ./app/$$_gendir/app.module.ngfactory.ts 30:0-50
@ ./app/main.ts
@ multi ./app/main.ts

What are the steps to reproduce?

TestApp.zip

npm install
ng build --prod

What is the use-case or motivation for changing an existing behavior?

N/A

Which versions of Angular, Material, OS, TypeScript, browsers are affected?

This works with angular v4.2.6 but fails with v4.3.0/v4.3.1

@angular/cli: 1.2.1
node: 7.1.0
os: win32 x64
@angular/animations: 4.3.1
@angular/cdk: 2.0.0-beta.8
@angular/common: 4.3.1
@angular/compiler: 4.3.1
@angular/core: 4.3.1
@angular/flex-layout: 2.0.0-rc.1
@angular/forms: 4.3.1
@angular/http: 4.3.1
@angular/material: 2.0.0-beta.8
@angular/platform-browser: 4.3.1
@angular/platform-browser-dynamic: 4.3.1
@angular/router: 4.3.1
@angular/upgrade: 4.3.1
@angular/cli: 1.2.1
@angular/compiler-cli: 4.3.1

Is there anything else we should know?

A non-prod build works fine.

This was reported initially against angular CLI, but I was asked to report it here.
angular/angular-cli#7062

A number of others are experiencing it as well.

There is no reference to "material/material" in the source of the app, so there must be something in the framework that is referencing this path.

[andrewseguin]

I tried creating a new app through angular CLI but did not see the error come up. Can you try with 4.3.2?

[SteveHWork]

@andrewseguin Updating to 4.3.2 doesn't help, but by process of elimination I've worked out a line that determines whether the error occurs. I'm using the date picker and I had the following in my app.module.ts:

import { MdDatepickerModule, MdDatepickerIntl } from "@angular/material";
import { MdNativeDateModule, DateAdapter, MD_DATE_FORMATS, MD_NATIVE_DATE_FORMATS } from "@angular/material";

The important line is the bolded one below:

providers: [
        { provide: MD_DATE_FORMATS, useValue: MD_NATIVE_DATE_FORMATS }
    ],

With this provider included, the prod build fails; if I remove it, the build passes. This seems to be something that changed with 4.3.0.

[filipesilva]

Just wanted to mention that the CLI issue (angular/angular-cli#7062) has a repro as well.

Edit: nvm, the same repro is here.

[chuckjaz]

In 4.2 we would inline useValue data into the factory. In 4.3, if the useValue is a reference then we generate a reference to the value instead of copying the data. Unfortunately, the reference we are generating is to MD_NATIVE_DATE_FORMATS in @angular/material/material instead of @angular/material.

To temporarily work around this, change the material.metadata.json file to be:

{
    "__symbolic":"module",
    "version":3,"metadata":{},
    "exports":[{"from":"./typings/index"}],
    "flatModuleIndexRedirect": true,
    "importAs": "@angular/material"
 }

Note the additional "importAs" field.

I will work with @jelbourn to determine the right solution for this.

[jelbourn]

Going to apply this workaround today and will aim to get a release out early next week.

[BobBDE]

good news ! nice work @SteveHWork :D

[jelbourn]

@chuckjaz when I apply the workaround to the generated metadata redirects, I start getting a new error on our ngc-based CI tasks:

Can't export value MdAutocompleteModule in /usr/local/google/home/jelbourn/material2/dist/packages/demo-app/material/typings/index.d.ts from DemoMaterialModule in /usr/local/google/home/jelbourn/material2/dist/packages/demo-app/demo-material-module.ts as it was neither declared nor imported!

I'm wondering if this is a consequence of how we run ngc in our own tooling, since we copy the built material/cdk packages into the outDir for our development app due to angular/angular#12249

[tuurbo]

I get this error when I try to AOT the latest material2-builds. Is there a temporary workaround I can use for now?