Note: We are going to assume for the sake of this example that all the services we are going to reference are provided through our providers:  fields in our modules, but the recommendation is to avoid this pattern as much as possible - take advantage of Angular 6+'s providedIn: "root" property, available to you in @Provider decorators.
ConfigServicethat was previously provided to our
CustomerPortalModuleis what we need to get this all working, no problem, we can add it in like so:
ConfigServicerelies on the
PromotionService, so we include that. Still no luck.
CustomerCardcomponent also relies on its own dependencies to be provided in any module it uses. I'll end this here, but you can see, this becomes an unending chain of pain.
SharedModulepattern utilized so frequently in our Angular Application. If we dump all of our application dependencies in one place, this problem goes away, and we can just pass around a giant shared module, exporting all of its contents and providing them to every Module that needs it.
Again, because I think it's so important to emphasize - for the sake of this example, I will keep the providers imported through the module declarations, however it is even simpler when you use the ProvidedIn: "root" pattern
CustomerCardComponent is declared in this module. It's very simple, so you might think 'why bother', but the SCAM pattern relies on consistency to get the most out of it, and in the end, you'll be happier for it. You can see we also export the Component, and since we don't need this pipe used anywhere else, we sort of lock it behind this module.
CustomerPortalModulelooks like this:
CustomerPortalComponentreally only needs exports from the component library, and the
ShoppingCart, giving you at a glance, a much better idea of what this slice of our application is consuming. Then... what does our
ReorderPortal. No fuss, no muss.