Plugin discovery and swappability of themes

Problem/Motivation

Drupal Core is adding more and more YAML plugins discovery to the themes: breakpoints, layouts, SDC, icons, tokens and, soon 🤞, #3517033: Add a style utility API:

We do that to empower the front dev, to make they the owner of a shareable design implementation, providing plugins to be used by back devs and site builders:

Those changes are organized and described in #3533198: [Meta] Make Drupal the first "design-system native" CMS + Unify & simplify render & theme systems

However, by doing that, themes are not swappable anymore. They are now in the upstream instead of the end of the value chain, and uninstalling a theme is becoming difficult.

This topic was a discussed during the DrupalCon Rotterdam coffee breaks, so let's move the discussion here.

Steps to reproduce

Activate a theme with some SDC, use those SDC in a renderable array, uninstall the theme. What may happen is related to the way of the plugin (layout, field formatter, block, view style...) hosting the render array is managing dependencies: it can breaks (plugin not found exception) or uninstall the config entity where this plugin is used.

Proposed resolution

Change management

First, there may be a change management and "education" effort to do. Themes are not just a swappable bunch of templates overrides anymore. Picking a theme is a committing to a provider, like activating a module and using the plugins it provides.

It is like that since we introduced breakpoints plugins in 2014, but SDC is making it more obvious. Maybe the community is not aware of this and we need to communicate about this.

Moreover, if some project get "plugin not found error", that may mean they don't ::calculateDependencies() correctly, and we can mitigate that by implementing the FallbackPluginManagerInterface

A new Drupal extension?

Then, we can propose a new Drupal extension which:

• will accept all plugins already YAML discoverable in a theme + asset library discovery, but no template overrides & suggestions (so not managed by the ThemeManager)
• strictly forbid any PHP (no more preprocesses, PHP will simply not run) and they have strictly no dependencies (like themes before, to avoid people are bypassing the PHP restrictions in a companion module)
• but themes can declare a dependency to them, so they can become swappable again (careful with SDC plugin ID which has are prefixed by the provider)

So, 2 themes depending to the same set of this new extension will be come swappable.

Is it technically doable? What would be the name of such extension?

Leverage the upcoming Style API

Instead/alongside of a new extension, it would be better to bet on #3517033: Add a style utility API proposal (targeting 12.1):

• which is mainly focused on style utilities (applying a universal, specific style alteration from mutually exclusive set of design options), but which also have a related "theme to modes" mapping mechanism: #3613964: Use Style API to manage dark mode in themes and user settings
• modes are the usual suspects: color scheme, contrast, motion... themes are scoped by mode, and are swapable sets of asset libraries, design tokens overrides, and some light page renderable alterations
• so, if it fit what we call "theme" in the "I swap my theme and my plugins are missing"use case, we can address it by telling: "Don't swap your drupal theme, but your theme plugin"

Example, DaisyUI design system has themes: https://daisyui.com/docs/themes/

Instead of having each of those theme (corporate, forest, lofi, acid...) as a Drupal theme extension, and swapping the extension (example: from "lofi" to "acid"):

drush theme:enable daisyui_acid
drush config-set system.theme default daisyui_acid
drush theme:uninstall daisyui_lofi

We have a single "daisyui" Drupal theme extension with many theme plugins:

themes:
  attribute: "data-theme"
  target: html
  type: theme
  forest:
    lofi:
      label: "Lofi"
      modes:
        color: light
    acid:
      label: "Acid"
      modes:
        color: light

And swapping would be as easy as:

drush cset daisyui.settings theme.colot.light 'acid'

Other themes can add their own theme plugins.

User interface changes

None.

Introduced terminology

Maybe a new extension type name.

And the opportunity of clarifying what is a "theme".

API changes

Maybe a new extension type.

Data model changes

None

Release notes snippet

Not yet.