Consider adding back the 'every page' concept to libraries

What about starting with Option one and doing the others in a follow up?

Trouble with doing #1 first is that it's very easy for library definitions to get it wrong, this is why we removed it last time.

Possible #4 would be to collect/group assets by region.

Let's say a theme has:

header
content
left sidebar
right sidebar
footer

If we collect libraries for each region and render/group the assets for them independently, then some of the regions will be more or less static (like a header) and some will potentially change assets a lot more (like content).

This gets complicated though because we only load libraries once, so given the controller has to get rendered first usually, if that includes various libraries that are dependencies of other libraries, but only sometimes, then we could still end up with a lot of duplication.

What if we start with adding this behavior specifically only to global libraries in themes and just separate those out and look at expanding it in follow-ups? that it can't be configured incorrectly. And instead of adding it to libraries, we could add it somewhow to #attached?

E.g. something like extlink module that implements hook_page_attachments() could then do:

$attachments['#attached']['global_library'][] = 'extlink/drupal.extlink';

Aware that this while feature kind of conflicts with the whole idea of SDC, a theme that fully embraces SDC might not have any global libraries at all, but I assume you always have some base CSS stuff that's shared that's always loaded. Don't know...

@berdir so global libraries from themes are added in BareHtmlPageRenderer::systemPageAttachments().

// Attach libraries used by this theme.
$active_theme = \Drupal::theme()->getActiveTheme();
foreach ($active_theme->getLibraries() as $library) {
$page['#attached']['library'][] = $library;
}

We could make CssCollectionGrouper theme-aware, and then force assets into a new group when they're in one of those libraries.

#attached['global_libraries'] seems tricky to implement because normal libraries can depend on global libraries and vice versa so we'd still have to mush them together for ordering etc. in the asset logic.

Maybe we could separately add a list of global libraries (YAML file or wherever) with an alter hook specifically for customising the list, although probably it'd be weird to maintain that outside the library definitions.