It's very unclear why it's necessary to define

# This section is used by the contrib module, Component Libraries. It allows you
# to reference .twig files in your sass/ directory by using the Twig namespace:
# @STARTERKIT
component-libraries:
  STARTERKIT:
    paths:
      - components
      - templates

in your theme's *.info.yml file.

  • Why should a theme have multiple component libraries?
  • If you want to have multiple component libraries, why does a Drupal theme even need to be aware? i.e. why not let them be squished together for a given theme?
  • Why then not have multiple themes, or even modules, each defining their own set of components?
  • 80–99% of themes will define a namespace matching their theme name, so requiring to define this key/section in a theme's *.info.yml makes things unnecessarily repetitive and difficult
  • It's then also confusing to expose themes/STARTERKIT/components/components/foo/foo.html.twig as STARTERKIT/foo and themes/STARTERKIT/templates/bar/bar.html.twig as STARTERKIT/bar. A single component library should live a single parent directory.

Comments

Wim Leers created an issue. See original summary.

aleksip’s picture

aleksip
Primary language Finnish
Location Finland
commented

This isn't used only for multiple component libraries, it can also be used to create multiple Twig namespaces for a single component library.

E.g. in themes that integrate with Pattern Lab the component-libraries key can be something like this:

component-libraries:
  atoms:
    paths:
      - dist/_patterns/00-atoms
  molecules:
    paths:
      - dist/_patterns/01-molecules
  organisms:
    paths:
      - dist/_patterns/02-organisms

This is extremely useful as Pattern Lab supports these namespaces as well.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

Why not just use those as a directory structure? Why do they have to be namespaces? Them being namespaces results in conflicts when using subthemes.

aleksip’s picture

aleksip
Primary language Finnish
Location Finland
commented

Defining a root namespace and then using @root/00-atoms, @root/01-molecules etc. would work too, I guess. It is just that Pattern Lab supports these namespaces 'out of the box', and also that PL supports a number prefix for ordering (which can be changed without breaking anything in PL), and this is circumvented by the namespaces.

Ideally the same component library could be used in a Drupal theme and e.g. a Symfony bundle. Stuff like theme inheritance does complicate things, but it would be great to be able to keep component libraries as decoupled as possible, and to force as few Drupal related restrictions as possible. But I guess some restrictions are unavoidable.

justclint’s picture

justclint commented

Disregard my post. I realized I was accessing the incorrect directory.

johnalbin’s picture

johnalbin
they/他
Primary language English
Location Taipei, Taiwan
commented
Status: Active » Closed (works as designed)

Why should a theme have multiple component libraries?

It's unlikely a theme will ever need multiple "component libraries". But that's not the same thing as wanting multiple Twig namespaces.

There was no technical reason to limit the number of Twig namespaces. And I think aleksip explains their reasoning well in the above comments.

For myself, recently, I let Drupal define the @[theme name] Twig namespace that points at the THEME/templates directory and let this module define a @components Twig namespace that points at the THEME/components directory.

If you want to have multiple component libraries, why does a Drupal theme even need to be aware? i.e. why not let them be squished together for a given theme?

Drupal doesn't need to be aware. This module just makes it possible to talk to Drupal's instance of Twig. Twig does need to know about the namespaces, obviously.

Why then not have multiple themes, or even modules, each defining their own set of components?

You totally can. And then you don't need this module.

80–99% of themes will define a namespace matching their theme name, so requiring to define this key/section in a theme's *.info.yml makes things unnecessarily repetitive and difficult

You're not required to redefine the theme's default namespace.

It's then also confusing to expose themes/STARTERKIT/components/components/foo/foo.html.twig as STARTERKIT/foo and themes/STARTERKIT/templates/bar/bar.html.twig as STARTERKIT/bar. A single component library should live a single parent directory.

I moved away from using one namespace with mulitiple directories. Twig still supports this, so the module will too.