node: v8.11.0
npm: 5.7.1
Windows 10
"@angular/animations": "5.2.9",
"@angular/cdk": "5.2.4",
"@angular/common": "5.2.9",
"@angular/compiler": "5.2.9",
"@angular/core": "5.2.9",
"@angular/forms": "5.2.9",
"@angular/http": "5.2.9",
"@angular/platform-browser": "5.2.9",
"@angular/platform-browser-dynamic": "5.2.9",
"@angular/router": "5.2.9",
"@angular/compiler-cli": "5.2.9",
"@ngtools/webpack": "1.10.2",
"typescript": "2.7.2",
"webpack": "3.11.0",
md5-f0b8c518abb26a193af0bcc8f30e416e
export const ROUTES: Routes = [
{
loadChildren: "./student/student.module#StudentModule",
path: "student",
},
];
md5-e7a10b564180fa0d313282f215936794
export const ROUTES: Routes = [
{
loadChildren: "./question/question.module#QuestionModule",
path: "question",
},
{
loadChildren: "./settings/settings.module#SettingsModule",
path: "settings",
},
];
md5-3a45205546ad35e4cb93851dcbada23e
export const ROUTES: Routes = [
{
loadChildren: "./settings/settings.module#SettingsModule",
path: "settings",
},
];
md5-3f19d29e688da6758a8550ca397ad742
ERROR in NaNbut they point to different modules "(C:/Projects/Web/App/src/student/settings/settings.module.ts and "C:/Projects/Web/App/src/student/questions/settings/settings.module.ts"). Webpack cannot distinguish on context and would fail to load the proper one.
md5-756d7677d2415c0036307e492925ba21
{
"compilerOptions": {
"emitDecoratorMetadata": true,
"experimentalDecorators": true,
"lib": [ "es2015", "dom" ],
"module": "commonjs",
"moduleResolution": "node",
"removeComments": true,
"skipLibCheck": true,
"sourceMap": true,
"target": "es5"
},
"exclude": [
"node_modules"
]
}
md5-34de1bddda9d0557bccce7a39f96258b
const srcPath = path.resolve(__dirname, "App/src");
module.exports = {
entry: {
app: srcPath + "/main.ts",
polyfills: srcPath + "/polyfills.ts",
vendor: srcPath + "/vendor.ts",
},
resolve: {
extensions: [".ts", ".js"],
},
module: {
loaders: [
{
test: /(?:\.ngfactory\.js|\.ngstyle\.js|\.ts)$/,
loader: "@ngtools/webpack",
},
]
},
plugins: [
new AngularCompilerPlugin({
tsConfigPath: "./tsconfig.json",
entryModule: "./App/src/app.module#AppModule",
}),
new webpack.optimize.ModuleConcatenationPlugin(),
new HardSourceWebpackPlugin(),
]
};
I also had trouble with this. Didn't understand why absolute paths wouldn't work. The solution is that you have to be aware where your baseUrl is. See this comment on Stack Overflow: https://stackoverflow.com/questions/47601637/angular-4-could-not-resolve-submodule-for-for-routing#comment88223393_48028980
E.g., if you have "baseUrl": "./" in your root tsconfig.json, your absolute path probably begins with src/app/….
E.g., if you have "baseUrl": "./" in your src tsconfig.app.json, your absolute path probably begins with app/….
It all depends on how you set up your project structure and named your directories. In my case, I had to prepend a src/ to my absolute paths.
Are you still able to reproduce this issue with the latest version?
I'm still getting the issue. If I use the absolute path, the issue goes away. I have multiple modules with the same name but different paths. Any suggestions as to how to resolve this error? thanks
Angular: 7.1.3
webpack 4.23.1
@mgechev
Hello,
I also have this problem right now
I made a sample code: https://github.com/eggp/ng-7-lazy-build-error
my test build command: ng build --configuration=production
result:

master branch ng cli version: 7.1.3
cli7.2.1 branch is actual cli version
same here
We'll look at this during the weekly triage meeting.
Currently this is working as intended. Here's a workaround:
// student-routing.module.ts
export function _lc() {
return import("./settings/settings.module").then(m => m.SettingsModule);
}
export const ROUTES: Routes = [
{
loadChildren: "./question/question.module#QuestionModule",
path: "question",
},
{
loadChildren: _lc,
path: "settings",
},
];
// question-routing.module.ts
export function _lc() {
return import("./settings/settings.module").then(m => m.SettingsModule);
}
export const ROUTES: Routes = [
{
loadChildren: _lc,
path: "settings",
},
];
This is bad DX, so I'd suggest to keep the issue open until we figure out how to improve.
When i use @mgechev s Workaround tsLint will complain:
[ts] Dynamic import is only supported when '--module' flag is 'commonjs' or 'esNext'. [1323]
with my tsconfig.json like this:
{
"compileOnSave": false,
"compilerOptions": {
"baseUrl": "./",
"outDir": "./dist/out-tsc",
"sourceMap": true,
"declaration": false,
// "module": "es2015", // just Changed that
"module": "esnext",
"moduleResolution": "node",
"emitDecoratorMetadata": true,
"experimentalDecorators": true,
"target": "es5",
"typeRoots": [
"node_modules/@types"
],
"lib": [
"es2018",
"dom"
]
}
}
in JIT it will work regardless but fail in AOT.
my package.json deps:
"dependencies": {
"@angular/common": "^7.2.2",
"@angular/core": "^7.2.2",
"@angular/forms": "^7.2.2",
"@angular/http": "^7.2.2",
"@angular/platform-browser": "^7.2.2",
"@angular/platform-browser-dynamic": "^7.2.2",
"@angular/router": "^7.2.2",
"@ionic-native/core": "^5.0.0",
"@ionic-native/splash-screen": "^5.0.0",
"@ionic-native/status-bar": "^5.0.0",
"@ionic/angular": "^4.0.0",
"core-js": "^2.5.4",
"rxjs": "~6.3.3",
"zone.js": "~0.8.29"
},
Yes, won't work with AoT, you're right. The quickest workaround would be to rename one of the routes:
// question-routing.module.ts
export const ROUTES: Routes = [
{
loadChildren: "./settings/settings.module#QuestionSettingsModule",
path: "settings",
},
];
NO, you try full absolute path, working!
I add new branch to my test code(branch: test-absolute-path), check my diff https://github.com/eggp/ng-7-lazy-build-error/commit/c2405b2eaef1a31e39fedc1b879b490a4d52cecd
working lazy build, just change ng styleguide to relative path loadChildren ...
i would use the relative but i dont know until this problem is up :(
so it can be used with an absolute route, however the only question is how long it lasts
ps:
sorry my english is not the best
@eggp yes, absolute paths work as well. The bug is caused by using the same string as the value for loadChildren.
thx, so I understand the nature of the error
@mgechev 's work around solution will not work if you are using AOT. refer https://github.com/angular/angular/issues/23878
Rather another workaround I used in this instance would be to navigate back one directory level to distinguish the the path for loadchildren. This will only work if you have a folder structure that can accommodate this.
export const ROUTES: Routes = [
{
loadChildren: "../<whatever the folder name of parent module>/settings/settings.module#SettingsModule",
path: "settings",
},
];
I'm too lazy to rename my files for a workaround solution. I believe this issue will be fixed soon.
same issue here :(
Currently this is working as intended.
This undocumented, surprising behavior is working as intended?
This is bad DX, so I'd suggest to keep the issue open until we figure out how to improve.
What is DX?
Hello Everyone,
@farajfarook, thank you for your note, I resolve the issue in that way:
export const ROUTES: Routes = [
{
loadChildren: "../<whatever the folder name of parent module>/<some_prefix_1>settings/settings.module#SettingsModule",
path: "settings",
},
];
export const ROUTES: Routes = [
{
loadChildren: "../<whatever the folder name of parent module>/<some_prefix_2>settings/settings.module#SettingsModule",
path: "settings",
},
];
Thank you one more time!
@farajfarook Thanks for save my day :)
Closing this since the string-based loadChildren has been deprecated.
Please see https://angular.io/api/router/LoadChildrenCallback
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
@mgechev 's work around solution will not work if you are using AOT. refer https://github.com/angular/angular/issues/23878
Rather another workaround I used in this instance would be to navigate back one directory level to distinguish the the path for
loadchildren. This will only work if you have a folder structure that can accommodate this.I'm too lazy to rename my files for a workaround solution. I believe this issue will be fixed soon.