Here’s my .02 on this for what it’s worth (and the Angular team’s honestly). You should group your code by feature not by type. If your component is shared across the most of the app put it in a shared feature module: https://angular.io/docs/ts/latest/guide/style-guide.html#!#04-10. It will be eagerly loaded and it will be very clear what components are shared by your entire app.
Then you continue to group your code by feature: https://angular.io/docs/ts/latest/guide/style-guide.html#!#04-07. So, for example let’s say user profile is one of your features. Make a new folder named profile, create a profile module in it. Let’s say you have a profile photo component that lets users upload, crop, and set a profile photo. That’s only going to be needed by this feature, so in that same folder create profile-photo.component.ts and import it into the profile module. You’d also presumably create a profile service and import it into that module as well.
Now you have a nice self contained reusable module that’s isolated from the rest of your code and can easily be tested and reused. You’ve also eliminated duplication of component code because your profile photo component is only loaded with the profile feature, rather than being copied into every single lazy loaded module.
Now, there’s still an issue here a little because as I’ve complained about already Ionic only lazy loads individual pages, so if your profile feature needed two pages you’d be in trouble. All this really comes from the Ionic team going against Angular best practices and encouraging archaic design patterns like grouping by type instead of feature.
If Ionic supported lazy loaded modules instead of pages (they are working on this) this issue would be very minimal because most components you’d want to lazy load would be specific to a feature area of the app, but I’ve ranted enough on that topic already