Looking for ideas on component library structure

Design
1

I have build a set of about 30 UI components, some helpers and layouts. Plus some related services. When I originally started it was a monolithic addon containing all the components and services, I later split it all out into separate single component addons and services so it was easier to mix and match just what I needed for a particular project.

Now I am looking at making it available to others and I’m trying to decide if I should move back to a single addon for all the components and services or leave them as separate components.

Single component addons

####Pros

  • Easy to update a specific component.
  • Only components you use will be added to your payload. ####Cons
  • End user updating can be tricky, some components have dependencies on other addons that must be kept in sync.
  • Versioning is a pain.
  • Testing interaction with other components is more difficult

###Monolithic addon ####Pros

  • Versioning is easy.
  • Testing is less complicated.
  • End user updating is easy ####Cons
  • A lot of stuff you may not need will be included in your project.

###My question I’m looking for some insight into how others have approached this, Most Ember UI libraries I’ve seen are monolithic, but I’m wondering if there is anyone with experience in organizing as single a la carte addons and if there are some examples they can point me to for study.

2

I think glimmer uses broccoli-rollup and I don’t know much about it but it seems to me that if you create a monolithic addon now you can add rollup support later. Also for the internet Apps we create loading time and size don’t seem to matter. So I am for the Monolithic addon.

3

After writing out the topic I kind of came to the same conclusion about the monolithic addon. I am interested in tree shaking will be possible (for unused components) with dynamic component helper constructs like this being possible.


{{component someComponent }}