feat(@ngtools/webpack): allow custom lazy module resource #12593
Conversation
filipesilva
added
the
needs: discussion
| @@ -102,6 +102,7 @@ export interface AngularCompilerPluginOptions { | |||
| missingTranslation?: string; | |||
| platform?: PLATFORM; | |||
| nameLazyFiles?: boolean; | |||
| lazyModulesResource?: string; | |||
There was a problem hiding this comment.
I'm unsure what the final semantics here should be. Should we allow several extra lazy module resources? Each would be a file containing a loader and it will have all the lazy modules as context.
There was a problem hiding this comment.
Changed it always be an array.
| // versions (until the dynamic import appears outside of core I suppose). | ||
| // We resolve any symbolic links in order to get the real path that would be used in webpack. | ||
| const angularCorePackagePath = require.resolve('@angular/core/package.json'); | ||
| const angularCoreResourceRoot = fs.realpathSync(path.dirname(angularCorePackagePath)); |
There was a problem hiding this comment.
realpath might or might not play well with bazel and preserve-symlink. Just want to make sure it's taken into account.
There was a problem hiding this comment.
I think it should be ok since it's the realpath to a file that was already resolved via require.resolve (thus using Bazel resolution). It's also the same logic as before though, so this change isn't breaking that.
filipesilva
removed
state: WIP
needs: discussion
filipesilva
force-pushed
the
lazy-module-resources
branch
from
bf75794
to
3c70b49
Compare
filipesilva
added
the
target: major
|
We should consider exposing this via an CLI build option in the future. It can help in cases where you have your own resource loader, like custom routers. |
filipesilva
force-pushed
the
lazy-module-resources
branch
from
3c70b49
to
aa0a676
Compare
|
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. |
Fix #12591