LibraryDiscoveryParser overwrites theme CSS group ordering

Very frustrating to find out that using the "theme" category on a module's library, with a group value that is higher than CSS_AGGREGATE_THEME (100), does not allow the module's CSS to come after the theme's CSS in the DOM. Impossible to do simple CSS refinements when the module wants to do them.

I am glad I am not alone in this :)

For what it may be worth, here is my implementation of hook_css_alter that re-applies the group property from the library data:

function modulename_css_alter(&$css, \Drupal\Core\Asset\AttachedAssetsInterface $assets) {

  foreach($assets->getLibraries() as $name) {
    [$module, $id] = explode('/', $name);
    if ($module && $id) {
      $library = \Drupal::service('library.discovery')->getLibraryByName($module, $id);
      foreach($library['css'] ?? [] as $definition) {
        if (isset($definition['group']) && $path = $definition['data']) {
          if (isset($css[$path])) {
            $css[$path]['group'] = $definition['group'];
          }
        }
      }
    }
  }
}

It is probably not very efficient, but should only run when needed and then the alterations are cached.

Agree this is fairly frustrating and more than slightly nonsensical that there is no way to define a "base" SMACSS in a theme and make it appear first before module code and even before other SMACSS groups from the same theme.

Even stable9 theme in Drupal core suffers from this exact issue out of the box:

Given the following three examples...

stable9.libraries.yml:

 css:
    base:
      css/core/assets/vendor/normalize-css/normalize.css: { weight: -20 }

core.libraries.yml:

internal.jquery_ui:
  css:
    component:
      assets/vendor/jquery.ui/themes/base/core.css: { weight: -11.8 }
    theme:
      assets/vendor/jquery.ui/themes/base/theme.css: { weight: -11.8 }

system.libraries.yml:

base:
  css:
    component:
      css/components/ajax-progress.module.css: { weight: -10 }

One would expect normalize.css to be the first CSS file in the HTML, but in fact, it shows up last.

Expected result:

/core/themes/stable9/css/core/assets/vendor/normalize-css/normalize.css
/core/assets/vendor/jquery.ui/themes/base/core.css
/core/themes/stable9/css/system/components/ajax-progress.module.css
/core/assets/vendor/jquery.ui/themes/base/theme.css

Actual result:

/core/assets/vendor/jquery.ui/themes/base/core.css
/core/themes/stable9/css/system/components/ajax-progress.module.css
/core/assets/vendor/jquery.ui/themes/base/theme.css
/core/themes/stable9/css/core/assets/vendor/normalize-css/normalize.css

I've mentioned this issue in docs in two places:

• https://www.drupal.org/docs/develop/standards/css/css-file-organization →
  Diff: https://www.drupal.org/node/1887922/revisions/view/13469196/13569583 →
• https://www.drupal.org/docs/develop/theming-drupal/adding-assets-css-js-... →
  Diff: https://www.drupal.org/node/2216195/revisions/view/13563347/13569585 →

I think we have 2 Issues here:
1: group key is overwritten by LibraryDiscoveryParser (commit)
2: we can't disable grouping. CssCollectionGrouper only checks for preprocess key. Thus you can't use preprocess, but opt out of grouping. (commit)

For 2 it's debatable if 0 or -1 would be preferred.
Let me know what you think

fork

I am not yet 100% this issue is related but maybe the problem described in 🐛 Library gin_custom_css should depend on gin/gin for higher priority Active is something we should take into account here too.

I face the same issue. I need to load certain libraries from the modules after the theme libraries. The logic in the LibraryDiscoveryParser completely overrides any group settings done in the library. I feel it should be conditional rather(only applied if not set already).

There is no way to work around this other writing a hook_css_alter() to set the group again for the required libraries.