Repository navigation
Update the lazy loading information to CLI and v6 #24109
Description
I'm submitting a...
[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report
[ ] Performance issue
[ ] Feature request
[x] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question
[ ] Other... Please describe:
Current behavior
Current documentation shows non-relative paths being used for loadChildren
{
path: 'customers',
loadChildren: 'app/customers/customers.module#CustomersModule'
},
While this can work, it depends on the tsconfig baseUrl configuration.
In Angular CLI 1.x we had a baseUrl of src/, which made sense for single apps. Angular CLI 6.x adds multi project and library support, and as part of that we changed the baseUrl to be ./.
This was done because having a baseUrl pointing to a specific project affects path resolution in all projects. Having multiple baseUrl is also problematic because your app interprets paths in tsconfig in one way, and your lib in another way. And your editor in yet another way because tsconfig.app.json is not recognized by the editor.
For a non-relative path to a lazy route to work, now it would have to include src/: loadChildren: 'src/app/orders/orders.module#OrdersModule'.
To avoid confusion on the CLI we always used relative paths, since we didn't know what baseUrl users had in their configs.
Expected behavior
I suggest examples use relative paths, thus not depending on any baseUrl configuration on user projects:
{
path: 'customers',
loadChildren: './customers/customers.module#CustomersModule'
},
It would also be beneficial to add a note about how using non-relative paths works but they are based off baseUrl.
What is the motivation / use case for changing the behavior?
Show instructions for lazy modules that work in a newly generated CLI 6.x project.
Related to angular/angular-cli#10673 (comment)
Activity
jenniferfell commentedon May 24, 2018
filename=https://angular.io/guide/lazy-loading-ngmodules
@brandonroberts : If I understand, there are two issues here:
The style guide seems correct: Style 05-04
Is that correct?
brandonroberts commentedon May 25, 2018
Yes, that's correct
montella1507 commentedon Sep 10, 2018
@filipesilva i think angular 6 has again problems with lazy loaded modules if there are 2+ unlisting in path..
if path in loadChildren contains 2+ times "../" it is error in first build (how ever it works in rebuild on watch)
//PROJECT STRUCTURE: portal/routing/portal.routing.ts, help/help.module.ts - you have to go 2 directories "up" to reach help.module.ts
= DOESNT WORK
//PROJECT STRUCTURE: x/x.routing.ts, help/help.module.ts - you have to go only one directory "up" to reach help.module.ts
loadChildren: '../help/help.module#HelpModule'
= DOES WORK
I am pretty sure you have solved this issue year ago and it is back.
filipesilva commentedon Sep 10, 2018
@montella1507 can you make a simple repro and open an issue with it in https://github.com/angular/angular-cli please? Then we can investigate it.
montella1507 commentedon Sep 11, 2018
@filipesilva angular/angular-cli#12236
i have tried to simulate it on stackblitz, without success, but i have added zip file and explained the problem as much as possible. Thank you.
filipesilva commentedon Sep 11, 2018
Thanks for the repro @montella1507, it really helps a lot. I triaged it and we should get to it as time allows.
montella1507 commentedon Sep 11, 2018
@filipesilva thank you for your time i think you have already faced this issue in the past. Maybe it is only lack in documentation and relative path is between module importing routes and another module and not "routing file". I am pretty sure you will figure it out. Thank you again.
brandonroberts commentedon Oct 8, 2018
Fixed via #20023
angular-automatic-lock-bot commentedon Sep 14, 2019
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.