Skip to content

Move NgModuleFactoryLoader from core to router #23796

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
dawidgarus opened this issue May 9, 2018 · 11 comments
Closed

Move NgModuleFactoryLoader from core to router #23796

dawidgarus opened this issue May 9, 2018 · 11 comments
Labels
area: core Issues related to the framework runtime
Milestone

Comments

@dawidgarus
Copy link

I'm submitting a...


[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[ ] Performance issue
[x] Feature request
[ ] 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

NgModuleFactoryLoader and SystemJsNgModuleLoader are defined in @angular/core

Expected behavior

They should be defined in @angular/router or other module.

Minimal reproduction of the problem with instructions

N/A

What is the motivation / use case for changing the behavior?

  1. NgModuleFactoryLoader is not used anywhere in core or in any module other than router
  2. NgModuleFactoryLoader is provided in router
  3. This change would probably allow us to use DllPlugin with @ngtools/webpack. See this issue: @ngtools/webpack :: Lazy Loaded Routes Not Built In Build With DLL Bundles angular-cli#4565.
    Currently @angular/core cannot be compiled separately from main app bundle as dll, because lazy loading chunks are not generated then. And because everything depends on @angular/core, all angular packages cannot be in dll. If SystemJsNgModuleLoader was in @angular/router, all other angular packages could be included in dll.

Environment


Angular version: 6.0.0
@mlc-mlapis
Copy link
Contributor

@dawidgarus ... we use NgModuleFactoryLoader and SystemJsNgModuleLoader regardless of the Router ... for programmatic loading of lazy loaded modules. For us it is just a core functionality.

@dawidgarus
Copy link
Author

@mlc-mlapis May I ask where? I didn't find any reference to NgModuleFactoryLoader or SystemJsNgModuleLoader in animations, common, compiler, compiler-cli, core (only definition, not used), forms, platform-browser, platform-browser-dynamic, upgrade.
Anyway, maybe consider moving it to @angular/core/factory-loader (or other name) then? It would still allow us to use DllPlugin for all the module that don't depend on it, which are all except router.

@mlc-mlapis
Copy link
Contributor

@dawidgarus ... ah, my comment was that we use them in our own code - we import them from core right now. I tried to say that the code is not specific just only for Angular Router module.

And @angular/core/factory-loader would be fine. I am just not sure if moving to router module and importing from there instead of core would also mean increasing size of bundles that don't use Router ... and how much.

@IgorMinar IgorMinar added area: router area: core Issues related to the framework runtime labels May 10, 2018
@ngbot ngbot bot added this to the needsTriage milestone May 10, 2018
@jasonaden
Copy link
Contributor

Thank you for the issue. However, these are consumed by the router, but can also be consumed by applications, and are a piece of core functionality. Therefore they should stay in @angular/core.

@mlc-mlapis
Copy link
Contributor

@dawidgarus ... I read your arguments why you have a problem with lazy loading chunks are not generated then but I still can't fully understand the reason how placing NgModuleFactoryLoader and SystemJsNgModuleLoader to Router module can help you. Especially when routes for lazy loaded modules are based on the principle of text path syntax.

@dawidgarus
Copy link
Author

dawidgarus commented May 16, 2018

@jasonaden If it's a core functionality, why do You have to import RouterModule to use it? To me, core functionality is something that is required for framework to work and it's not. It's just extra feature. Move it to separate package then, maybe '@angular/core/factory-loader` or something.

@mlc-mlapis in angular-cli issue referenced it's explained why. TL;DR version is that module which contains SystemJsNgModuleLoader cannot be prebuild when using webpack - it must be build together with app. That's why You cannot use DllPlugin or umd bundles that angular provides.

@mlc-mlapis
Copy link
Contributor

mlc-mlapis commented May 16, 2018

@dawidgarus ... so 2 questions:

@dawidgarus
Copy link
Author

@mlc-mlapis AngularWebpackPlugin somehow change module dependencies during build to include lazy loaded modules. Obviously it can do so only if it's build together with app. What's so special about SystemJsNgModuleLoader it's that it creates webpack's ContextModuleFactory.

@mlc-mlapis
Copy link
Contributor

@dawidgarus ... hmm, thanks for additional info. We don't use Webpack so that's why the questions.

@trotyl
Copy link
Contributor

trotyl commented Aug 5, 2018

@jasonaden NgModuleFactoryLoader is indeed part of @angular/core, but SystemJsNgModuleLoader is a platform-specific implementation and should be in @angular/platform-browser.

Anything being platform-independent would only consume abstract NgModuleFactoryLoader token rather than SystemJsNgModuleLoader provider, and user can always provide a different implementation.

@angular-automatic-lock-bot
Copy link

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.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 13, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area: core Issues related to the framework runtime
Projects
None yet
Development

No branches or pull requests

5 participants