When using ng-packagr, I receive a build error "ENOENT: no such file or directory, open '.../node_modules/@angular/packages/material...'
It packages properly with no build errors.
It errors out and doesn't build successfully but I can do ng build without issues.
ng new material-test
npm install
. ng-packagr -p ng-package.json
. OR
npm install
npm run packagr
To be able to use ng-packagr with beta.12 in personal libraries.
@angular 4.4.4
Material 2.0.0-beta.12
TypeScript 2.3.3
I also receive messages during the ng-packagr process stating a number of items are imported but never used even if I only import one module from material library. See file below for said messages. In this particular test project, I'm only importing MatIconModule into the main app module. If I run ng-packagr on beta.11, I don't receive the build error but still get the imported but not used messages and it successfully builds. I will also be submitting this to the ng-packagr project as I'm not sure if this an ng-packagr issue or material beta.12 issue but I only get the issue if I import any module from material beta.12. And also putting on Stack Overflow in case it's just an issue that I'm causing due to something I'm doing wrong, in which case I apologize for submitting this issue.
EDIT: ng-packagr issue can be tracked here #172
I'm not really sure what that is. We maintain our own packaging tooling currently with gulp.
gulp material:build-release
I don't think this should have been closed. Some clarification: we aren't trying to use ng-packagr to build material itself. We are working on library projects that include material, and using ng-packagr to build those. The problem seems isolated to the esm5 packaging of material, which I am guessing not many people are using or else this issue would have much more traffic.
Is there a working example of a project successfully using beta.12's esm5 packaging anywhere?
Edit: I have another project that is using a custom rollup configuration only building umd and fesm modules successfully with material beta.12, so I really think its an issue specific to the esm5 packaging.
I agree with @matt328 , it is very important for us to be able to use Material in our own component libraries. Something must have changed between beta.11 and beta.12 to break what ng-packagr is trying to accomplish. I am seeing the same issue and looking forward to your insight, @jelbourn
It's impossible for me to say what the issue might be, since this is the first time I've heard of this tool. We unfortunately don't have the capacity to track down issues with 3rd party tools; if someone is able to point to a specific issue with the package output, we can make any necessary changes to the packaging.
@nmrichards I only have brief experience with ng-packagr, but it looks like you're trying to bundle @angular/material
_with_ your component library. Does it work with setting it as a peer dependency instead? It appears that @angular/cdk/*
are listed as externals by default, but @angular/material
should be added as one in order to not bundle it with your lib.
@jelbourn it does look like there is an invalid sourcemap url (also could be my own ignorance about how they work).
_maybe_ from #7403
We are removing sorcery until we can upgrade tsickle and ngc to latest. Our versions of these break when mapping all the way back to TS. (temporary)
@willshowell I'll defer any sourcemap stuff to @kara
@willshowell adding material to lib.externals in ng-package.json:
{
"lib": {
"entryFile": ...,
"externals": {
"@angular/material": "ng.material"
}
}
seems to have fixed my issue, my library is now building successfully with ng-packagr.
That is not to say there still isn't some issue here with the esm5 packaging's sourcemaps. I think someone consuming the esm5 package would likely face the same errors.
Hi @jelbourn,
author of ng-packagr here. It's a tool for (publicApi: TypeScriptFile) => { fesm5, fesm15, umd, ... }
compiling/bundling, pretty much like angular-quickstart-lib in a CLI command.
Two observations:
1) Users need to configure their external dependencies. rxjs
and some @angular/*
core packaged are pre-configured. @angular/material
is not on the list.
2) On sourcemaps, there had been some issues w/ the ng
CLI in the past. It could happen sourcemaps of a library were corrupt and then some of the webpack tools produced build errors. Error was in build of an app depending on a lib; not in library build.
For your concerns, sourcemaps could potentially break a user's build. Someone would need to find a repro.
Just my two cents, but I've found ng-packagr to be a great tool for packaging/publishing reusable components.
The suggestion from @matt328 worked for me as well.
@matt328 I spent 2 days on this. This saved some other days I was going to waste. Thank you!
I'm having the same issue with @angular/material and the "externals" fix has not resolved it.
{
"$schema": "./node_modules/ng-packagr/package.schema.json",
"ngPackage": {
"lib": {
"entryFile": "public_api.ts",
"externals": {
"@angular/material": "ng.material"
}
}
}
}
I'm getting:
BUILD ERROR
ENOENT: no such file or directory, open '...\node_modules\@angular\packages\material\esm5\core\animation\animation.js.map'
Error: ENOENT: no such file or directory, open '...\node_modules\@angular\packages\material\esm5\core\animation\animation.js.map'
@drullo I think you may need to check the relative path of your node_modules file. Also for some reason I do not see ngPackage in my ng-package.json. Here is how this file look like in my end:
{
"$schema": "./../../node_modules/ng-packagr/ng-package.schema.json",
"lib": {
"entryFile": "index.ts",
"externals": {
"@angular/material": "ng.material"
}
}
}
@drullo Did you try to add each submodule of @angular/material
like this :
{
"$schema": "./node_modules/ng-packagr/ng-package.schema.json",
"lib": {
"entryFile": "public_api.ts",
"externals": {
"@angular/material": "ng.material",
"@angular/material/icon" : "ng.material.icon",
"@angular/material/toolbar" : "ng.material.toolbar"
}
}
}
@mohyeid, you're right that "ngPackage" didn't belong in the ng-package.json file. Originally, I had my configuration placed into the package.json file - which does require it to be in the "ngPackage" section. When I transitioned my configuration from package.json to ng-package.json, I forgot to remove the "ngPackage" wrapper initially.
@Fairen, that was not the problem initially. However, I did change the way that I'm importing Material modules in my code. Originally, I was importing them all from @angular/material (as this was the way that the material.angular.io documentation instructed users until very recently). But their documentation has changed and I have since learned that that approach (importing modules from "parent" modules that re-export them) is bad for tree shaking and inefficient for AOT. So I have updated my code to import the Material modules individually and yes - after that I did have to add each submodule to the "externals" section of ng-package.json individually.
Incidentally, I also had to add angular2-jwt, in case anybody else is using it.
@drullo - your method worked for me as well. I had to go back and modify all of my imports to the latest approach.
"externals": {
"@angular/material/autocomplete": "ng.material.autocomplete",
"@angular/material/input": "ng.material.input",
"@angular/material/select": "ng.material.select"
}
I'm still having this issue with my particular build. @drullo @jrc60752 I figure you are using Material modules that rely on anomations, did you also have to add an "externals" entry along the lines of:
"@angular/material/core/animation": "ng.material.core.animation",
For the specific animation.js.map error? In spite of the fact that nobody (I suspect) actually imports that _directly_ in TS code. That said, when I try this, it doesn't seem to help...
@scottmcmaster no, I didn't not have to add an entry for @angular/material/core/animation
. Can you post your error and a copy of your ng-package.json?
I had to go back and refresh my memory...a few weeks off and I forgot what this was referring to.
my complete ng-package.json file contains:
{
"lib": {
"entryFile": "public_api.ts",
"externals": {
"@angular/material/autocomplete": "ng.material.autocomplete",
"@angular/material/input": "ng.material.input",
"@angular/material/select": "ng.material.select"
}
}
}
and public_api.ts contains (names are a bit odd as I had to change a view names to remove company info):
export * from './src/app/modules/my-custom-selector/my-custom-selector.module';
my-custom-selector.module contains:
import { NgModule } from '@angular/core';
import { BrowserModule } from "@angular/platform-browser";
import { CommonModule } from '@angular/common';
import { FormsModule, ReactiveFormsModule } from "@angular/forms";
import {MyCustomSelectorComponent} from './my-custom-selector.component';
import {MyCustomPersonnelFinderService} from './my-custom-personnel-finder.component';
import {MatAutocompleteModule} from '@angular/material/autocomplete';
import {MatInputModule} from '@angular/material/input';
import {MatSelectModule} from '@angular/material/select';
import {BrowserAnimationsModule} from '@angular/platform-browser/animations';
@NgModule({
imports: [
BrowserModule,
FormsModule,
ReactiveFormsModule,
CommonModule,
MatAutocompleteModule,
MatInputModule,
MatSelectModule,
BrowserAnimationsModule,
],
declarations: [MyCustomSelectorComponent],
providers: [MyCustomPersonnelFinderService],
exports: [MyCustomeSelectorComponent]
})
export class MyCustomSelectorModule {}
With the above, I was able to package everything up with no issues and import into a co-workers application as a test.
@drullo sure, thanks :).
Here is the packaging output:
`Building Angular library
Generating bundle for my-project
Cleaning bundle build directory
Processing assets
Running ngc
Compiling to FESM15
'LOCALE_ID' is imported from external module '@angular/core' but never used
BUILD ERROR
ENOENT: no such file or directory, open 'G:myprojectdirectorynode_modules@angularpackagesmater
ialesm5coreanimationanimation.js.map'
Error: ENOENT: no such file or directory, open 'G:myprojectdirectorynode_modules@angularpackage
smaterialesm5coreanimationanimation.js.map'`
And here is my ng-package.json:
{
"$schema": "./node_modules/ng-packagr/ng-package.schema.json",
"lib": {
"entryFile": "public_api.ts",
"externals": {
"@angular/material": "ng.material",
"@angular/material/button": "ng.material.button",
"@angular/material/dialog": "ng.material.dialog",
"@angular/material/menu": "ng.material.menu",
"@angular/material/core/option": "ng.material.core.option",
"@angular/material/select": "ng.material.select",
"@angular/material/tabs": "ng.material.tabs",
"angular-tree-component": "angular-tree-component",
"ng-drag-drop": "ng-drag-drop"
}
}
}
Update: I revved some components just for the heck of it, and now it packages ok. Here is the diff. Doesn't seem like it should be too significant, but in case this helps somebody:
- "@angular/animations": "^5.1.0",
+ "@angular/animations": "^5.2.0",
- "@angular/cdk": "^5.0.1",
+ "@angular/cdk": "^5.0.4",
- "@angular/material": "^5.0.1",
+ "@angular/material": "^5.0.4",
What is the preferred way to use @angular/material in your library project? Is the process defined?
When using ng-packagr to package a component with @angular/material I recieve a build error : mat-toolbar not found ( sale message for all other material tag mat-icon, mat-xxx)
I鈥檝e added @angular/material submodule in my ng-package.json as stated above but that did not solve my problem
Any idea ?
@matt328 your suggestion below don鈥檛 work for me. You confirm that it need just to add externals libs ?
Thanks you
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
@willshowell adding material to lib.externals in ng-package.json:
seems to have fixed my issue, my library is now building successfully with ng-packagr.
That is not to say there still isn't some issue here with the esm5 packaging's sourcemaps. I think someone consuming the esm5 package would likely face the same errors.