Bug
ng build --prod should complete without errors.
Prod build fails with:
ERROR in ./app/$$_gendir/app.module.ngfactory.ts
Module not found: Error: Can't resolve '@angular/material/material'
in 'C:\Codeapp$$_gendir'
@ ./app/$$_gendir/app.module.ngfactory.ts 30:0-50
@ ./app/main.ts
@ multi ./app/main.ts
npm install
ng build --prod
N/A
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
A non-prod build works fine.
This was reported initially against angular CLI, but I was asked to report it here.
https://github.com/angular/angular-cli/issues/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.
I tried creating a new app through angular CLI but did not see the error come up. Can you try with 4.3.2?
@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.
Just wanted to mention that the CLI issue (https://github.com/angular/angular-cli/issues/7062) has a repro as well.
Edit: nvm, the same repro is here.
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.
Going to apply this workaround today and will aim to get a release out early next week.
good news ! nice work @SteveHWork :D
@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 https://github.com/angular/angular/issues/12249
I get this error when I try to AOT the latest material2-builds. Is there a temporary workaround I can use for now?
use these option with build command -prod -aot false
@jelbourn is there any update on this?
Does beta.10 still have this problem?
@jelbourn I encountered this error previously in our builds, and temporary workaround was to disable --aot. I reactivated --aot it and it seems to work now, at least for me.
Angular: v4.3.6
Material: v2.0.0-beta.10
Typescript: v2.3.4
Fixed for me as well since beta.10. I think this can be closed now. Thanks for the fix.
This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
_This action has been performed automatically by a bot._
Most helpful comment
Going to apply this workaround today and will aim to get a release out early next week.