Library gin_custom_css should depend on gin/gin for higher priority

#2 patch still not being able to override gin/gin.

Yes, I've been trying to fix this. I don't think that the proposed solution it the right way to tackle this. The issue is that the weight of the attached css file get's ignored. This might actually be a drupal core bug.

If it's a Drupal core issue, it should be caused by the AssetResolver::getCssAssets() method somewhere, though it seems to follow the exact same logic with the ::getJsAssets() method which - from what I know - hasn't caused any issues.

There might exist a logic that not-processed CSS files get loaded first or at least before the rest of the aggregated files of the same module.

Check the attached screenshot. The red arrow points to our gin-custom.css file whereas the blue button points to the aggregated CSS file containing the rest of Gin's code.

I suggest we read CSS File Organization → and 🐛 LibraryDiscoveryParser overwrites theme CSS group ordering Active before we come up with another issue in Drupal Core.

Notice: Setting as "Needs Review" in order to attract more people for review of how we should go on from here.

Ok I found a fix, but I'm unable to commit the modification to the MR.

Here's what I did and works.

in the library file,

# Custom CSS

gin_custom_css:
  css:
    theme:
      public://gin-custom.css: { preprocess: true, minified: true, weight: 50 }

Because the maximum weight for css is 50 according to the documentation

and then I changed the the gin.theme

/**
 * Set Gin CSS on top of all other CSS files.
 */
function gin_css_alter(&$css, $assets) {
  // Use anything greater than 100 to have it load after the theme
  // as CSS_AGGREGATE_THEME is set to 100.
  // Let's be on the safe side and assign a high number to it.
  $base_css = \Drupal::service('extension.list.theme')->getPath('gin') . '/dist/css/base/gin.css';

  if (isset($css[$base_css])) {
    $css[$base_css]['group'] = 0;
  }
}

Because it was set to 200 so it came after everything else.

@selfirian, you suggestion was great, thanks a lot!

Though, since gin.css had this group for a reason I supposed, instead of setting it to 0, I preferred to do the following:

// The gin-custom.css file should be loaded just after our gin.css file.
$custom_css = 'public://gin-custom.css';
if (isset($css[$custom_css])) {
  $css[$custom_css]['group'] = 201;
}

This change has the following result:

Please review.

There are a couple of minor issues reported by PHPCS, on the gin.theme file.

Just remove the spaces at the end of line 23, and the extra blank line at the end of the file, and push, and everything should be fine.

Thank you @lostcarpark. PHPCS issues are now fixed too.

I carried out a test in DrupalPod, and created a gin-custom.css file in my files directory, and verified that styles from it took priority over Gin default styles:

This seems to fix the problems, and as tests are passing, I think this can go to RTBC.

Wouldn't it be better if the custom css related code is all grouped in the inlcude/page.theme?

I think that's a preference issue. I left it where I found it: https://git.drupalcode.org/project/gin/-/blob/8.x-3.x/gin.theme?ref_type.... I don't honestly think this kind of change should be addressed in this issue - seems out of scope. But whatever the maintainers decide.

Yes, the bug is fixed that's the most important part. Thanks for the help.

Thanks y'all 👏

Automatically closed - issue fixed for 2 weeks with no activity.