[AoT] [ngc] Re-exports causing build error during #482
Comments
|
I just added tried this out in the ng-packaged repository and I get the same error. So it looks like reexports aren't supported by this tool. Any reason? |
|
one last update, it seems to work if you remove the file name |
|
Here is a version of the packager repo that exhibits the problem. https://github.com/babeal/ng-packaged |
|
When the ngc configuration is set to output a flatModuleOutFile, it runs code in the bundler.ts file which sadly is broken. It tries to resolve the symbol for the symbolic reference to the shared module and it's canonicalSymbol declaration reference is null. Can you link these issues? |
|
Not a v1 issue. issue reproducible in v2 with angular 5. By applying this change set, the compile error goes away. diff --git a/my-lib/src/lib.module.ts b/my-lib/src/lib.module.ts
index 0ad912a..ef862f8 100644
--- a/my-lib/src/lib.module.ts
+++ b/my-lib/src/lib.module.ts
@@ -2,7 +2,7 @@ import { NgModule, ModuleWithProviders } from '@angular/core';
import { CommonModule } from '@angular/common';
import { FooComponent } from './foo/foo.component';
import { BarService } from './bar/bar.service';
-import { SharedModule } from './shared/index';
+import { SharedModule } from './shared/shared.module';
@NgModule({
imports: [On first sight, it looks related to TypeScript barrels (#195). But, the import was explicit to the Here are the bundle indexes: $ cat my-lib.d.ts /**
* Generated bundle index. Do not edit.
*/
export * from './public_api';
export { SharedModule as ɵa } from './shared/shared.module';$ cat my-lib.metadata.json {
"__symbolic": "module",
"version": 4,
"metadata": {
"BarService": {
"__symbolic": "class",
"decorators": [
{
"__symbolic": "call",
"expression": {
"__symbolic": "reference",
"module": "@angular\/core",
"name": "Injectable",
"line": 5,
"character": 1
}
}
],
"members": {
}
},
"FooComponent": {
"__symbolic": "class",
"decorators": [
{
"__symbolic": "call",
"expression": {
"__symbolic": "reference",
"module": "@angular\/core",
"name": "Component",
"line": 2,
"character": 1
},
"arguments": [
{
"selector": "my-foo",
"template": "<h1>foo<\/h1>",
"styles": [
"h1 {\n color: #ff00ff; }\n"
]
}
]
}
],
"members": {
}
},
"MyLibModule": {
"__symbolic": "class",
"decorators": [
{
"__symbolic": "call",
"expression": {
"__symbolic": "reference",
"module": "@angular\/core",
"name": "NgModule",
"line": 6,
"character": 1
},
"arguments": [
{
"imports": [
{
"__symbolic": "reference",
"name": "\u0275a"
}
],
"declarations": [
{
"__symbolic": "reference",
"name": "FooComponent"
}
],
"exports": [
{
"__symbolic": "reference",
"name": "FooComponent"
}
]
}
]
}
],
"members": {
},
"statics": {
"forRoot": {
"__symbolic": "function",
"parameters": [
],
"value": {
"ngModule": {
"__symbolic": "reference",
"name": "MyLibModule"
},
"providers": [
{
"__symbolic": "reference",
"name": "BarService"
}
]
}
}
}
},
"\u0275a": {
"__symbolic": "class",
"decorators": [
{
"__symbolic": "call",
"expression": {
"__symbolic": "reference",
"module": "@angular\/core",
"name": "NgModule",
"line": 3,
"character": 1
},
"arguments": [
{
"imports": [
{
"__symbolic": "reference",
"module": "@angular\/common",
"name": "CommonModule",
"line": 5,
"character": 4
}
]
}
]
}
],
"members": {
}
}
},
"origins": {
"BarService": ".\/bar\/bar.service",
"FooComponent": ".\/foo\/foo.component",
"MyLibModule": ".\/lib.module",
"\u0275a": ".\/shared\/shared.module"
},
"importAs": "@my\/lib"
} |
dherges
changed the title
|
I got the same issue in my project. We defined the following rule for our development "Export from barrels, but only explicitly import from single files instead of barrels". Is there a solution on your side to fix this in an upcoming version? It would make our code more lean if imports from barrels are possible (e.g. in routing-modules defining routes and navigation structure) |
|
Looking for a workaround as well. Our library uses barrels everywhere (because they are so convenient!). |
|
@chillinski The metadata is generated by |
|
Same issue for me. Noob in npm/angular and stuff, though. Any resolution? I will be trying to remove all index.ts files, see what works. Update: removed all index.ts files, imported directly from the component .ts files and packagr worked just fine. |
|
@Siderite you have to export all components, modules and pipes out of the index file that ng packagr uses. That means that you can’t have any private modules used only internally. They have to all be exported towards the top level |
|
@babeal I just import external types when Just need to take care when working with barrels, they don't work quite well with |
|
We have a fairly large project that extensively uses index files. I am trying to run ng-packagr against our code base and have run into this issue. It is unclear to me from reading this thread whether this issue has/will be fixed or whether we can only use ng-packagr if we eliminate our use of index files (a very big effort!)? This seems like it would be a very common issue. |
|
@twilson7755 index files aren't the issue. It's the import path to the file from an entry point. The problem isn't in ng-packagr but with the @angular/compiler. So if you have any private imports they don't have a path to the entry point and don't get populated with the correct metadata. |
I did get a similar issue due to Typescript Barrels. My secondary entry point uses a barrel but didn't export all the component which were imported elsewhere this lead to the creation of an extra file with this forgotten to export component: As multiple of my libraries had the same issue it complained about re-exporting the same symbol. I could resolve the issue by exporting the Hope this can help in resolving this issue |
|
In Angular, the error occurs when importing stuff from barrels in a module or routing file. As many people said in above comments, the error disappears when one imports the component/service from the actual file path and not from the barrel. It would be really wonderful if at least the error message was a bit more descriptive because this minor issue can make people waste a lot of time. |
|
The error message improvement has to be done in the angular compiler. I’ve been meaning to do it but haven’t gone through the process of signing the cla. So it would be better to open an issue to improve the error messages on the angular compiler; most likely this already been done but can’t remember |
dherges
changed the title
|
Any news? |
|
This frequently affects me when working on a large project and I spend way too much time finding out what export is missing. The error message is useless. |
|
Thanks for reporting this issue. This issue is now obsolete due to changes in the recent releases. |
|
This issue has been automatically locked due to inactivity. |
Type of Issue
Getting
Description
The error occurs when I import the shared module from the index.ts file. i.e.
import { SharedModule } from "./shared/index". If I import directly from the shared.module the error goes away. I've never had a problem using index files before and would like to know more about why it's failing.index.ts
shared.module.ts
How To Reproduce
Expected Behaviour
I can import reexports properly without getting cryptic error.
Version Information
The text was updated successfully, but these errors were encountered: