LoadChildren - lazy loaded routes and relative path problems #12236
Comments
|
That We should also be consistent in these build errors: it should happen on both builds and rebuilds and not just one of these. |
|
I had same problem. Fixed it by moving RouterModule.forRoot(mainRoutes) from AppRoutingModule to AppModule imports (and removing AppRoutingModule from AppModule imports). |
|
Yeah. Same here, but it should not be ignored (this bug) |
|
I have looked into this and the build should fail. Because lazy loaded routes are relative to the module were they are register not the const file. In your case the correct relative path should be That said, I am going to leave this open so that we look into why the error message is not always displayed. |
|
@alan-agius4 well.. then you are able to build that but it will throw error when navigated in browser i think ;-) |
|
@montella1507 It works in the browser |
|
@alan-agius4 @filipesilva can we add that very important information (relative to module, not file) to documentation ? |
* fix(@ngtools/webpack): emit lazy routes errors on rebuilds At the moment lazy route errors are only emitted in the initial builds because in following builds we are only processed lazy routes that are declared in the changed files. At the moment, we cannot cache the previously resolved routes as there is no way to track in which file the lazy route was declared so that we can bust the lazy route if it was removed. Closes #12236 * test: add test for compilation errors in watch mode Closes #12311
|
@alan-agius4 So why does this work in Angular 5 and 6 but now all of a sudden it gives error?
Surely you should be able to specify it from the root of your project? |
|
Non-relative paths will be evaluated from the tsconfig’s baseUrl. |
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
…2418) * fix(@ngtools/webpack): emit lazy routes errors on rebuilds At the moment lazy route errors are only emitted in the initial builds because in following builds we are only processed lazy routes that are declared in the changed files. At the moment, we cannot cache the previously resolved routes as there is no way to track in which file the lazy route was declared so that we can bust the lazy route if it was removed. Closes angular#12236 * test: add test for compilation errors in watch mode Closes angular#12311
Bug Report or Feature Request (mark with an
x)Command (mark with an
x)Versions
NPM 6.2.0
Node v10.9.0
Angular CLI: 6.0.8
Node: 10.9.0
OS: win32 x64
Angular: 6.1.4
Package Version
@angular-devkit/architect 0.6.8
@angular-devkit/build-angular 0.6.8
@angular-devkit/build-optimizer 0.6.8
@angular-devkit/core 0.6.8
@angular-devkit/schematics 0.6.8
@angular/cli 6.0.8
@ngtools/webpack 6.0.8
@schematics/angular 0.6.8
@schematics/update 0.6.8
rxjs 6.2.2
typescript 2.7.2
webpack 4.8.3
Repro steps
To simulate this you have to download source code here (because stackblitz cannot even generate working, ready to download solutions...):
load-children-issue.zip
NG serve = error:
ERROR in Could not resolve module ../../room/room.module relative to /D/GIT/angular-empty/bara2/src/app/layout/layout.module.ts
if you check layout.module.ts, routing is imported via index.ts files - importing layoutRouting (layout.routing.ts)
BUt it works when you resave anything (when project is rebuilt on watch. )
Check this picture please:
Expected behavior
There should be no problem with index.ts files regarding the relative path in loadChildren.
Desired functionality
LoadChildren relative path shoudl work regardless the folder "deepness"
Mention any other details that might be useful
The text was updated successfully, but these errors were encountered: