CssCollectionOptimizerLazy::generateHash doesn't allow for absolute paths in assets

Temporary workaround

/**
 * Implements hook_library_info_alter().
 */
function YOURTHEME_theme_library_info_alter(array &$libraries, string $extension): void {
  if (!in_array($extension, ['SOME_THEMES', 'YOU_CARE_ABOUT'], TRUE)) {
    return;
  }
  $deploymentIdentifier = Settings::get('deployment_identifier', \Drupal::state()->get('system.css_js_query_string', 0));
  foreach ($libraries as $key => $library) {
    if (!array_key_exists('version', $library)) {
      $libraries[$key]['version'] = $deploymentIdentifier;
    }
  }
}

Proposed resolution makes sense to me.

Hm, strange, we have plenty of libraries like this and didn't run into this issue. dropzonejs module, for example. Anything else going on here?

Ah, dropzonejs does have a version and so do probably most that are using /libraries, so I assume that's the issue. Sorry for the noise, ignore me and move on :)

I spent some time trying to reproduce this, and can't.

I tried to write some test coverage for this, and it passed locally.

Then I tried to reproduce manually.

If I put a URL like '/libraries/foo.css', then it works whether the libraries directory is in the root directory or in 'sites/default/libraries', this is because AssetGroupSetHashTrait already operates on assets that have been processed by \Drupal\Core\Asset\LibraryDiscoveryParser::buildByExtension

If I put a URL like '/core/misc/assets/foo.css' then that same logic converts it to a relative url 'core/misc/print.css' (the substr($source, 1) call).

The only way I can get file not found is to put a file that actually doesn't exist in, which I did just to make sure my changes were being picked up.

All I can think is maybe this isn't coming from the raw library definition but maybe an alter somewhere, but then that needs much more specific steps to reproduce.

For reference both of these work:

diff --git a/core/modules/system/system.libraries.yml b/core/modules/system/system.libraries.yml
index 2f510872d5..39c3edc0e1 100644
--- a/core/modules/system/system.libraries.yml
+++ b/core/modules/system/system.libraries.yml
@@ -1,5 +1,4 @@
 base:
-  version: VERSION
   css:
     # Adjust the weights to load these early.
     component:
@@ -12,7 +11,7 @@ base:
       css/components/details.module.css: { weight: -10 }
       css/components/hidden.module.css: { weight: -10 }
       css/components/item-list.module.css: { weight: -10 }
-      css/components/js.module.css: { weight: -10 }
+      /libraries/foo.css: { weight: -10 }
       css/components/nowrap.module.css: { weight: -10 }
       css/components/position-container.module.css: { weight: -10 }
       css/components/progress.module.css: { weight: -10 }

diff --git a/core/modules/system/system.libraries.yml b/core/modules/system/system.libraries.yml
index 2f510872d5..4c14d716cc 100644
--- a/core/modules/system/system.libraries.yml
+++ b/core/modules/system/system.libraries.yml
@@ -1,5 +1,4 @@
 base:
-  version: VERSION
   css:
     # Adjust the weights to load these early.
     component:
@@ -12,7 +11,7 @@ base:
       css/components/details.module.css: { weight: -10 }
       css/components/hidden.module.css: { weight: -10 }
       css/components/item-list.module.css: { weight: -10 }
-      css/components/js.module.css: { weight: -10 }
+      /core/misc/print.css: { weight: -10 }
       css/components/nowrap.module.css: { weight: -10 }
       css/components/position-container.module.css: { weight: -10 }
       css/components/progress.module.css: { weight: -10 }

Opened an MR with the extra (minimal) test coverage but leaving at needs more info.

I'm wondering if this was an alter hook adding something from the libraries directory, but without determining where the libraries directory actually is - however since it's altering information where that has already been resolved, I'm not sure core should be resolving it again just in case - we'd be running exactly the same logic twice then. Instead the alter code could resolve the libraries location and use that.

If I'm guessing correctly what the problem is at all of course.

Yep, re-investigated this and you're right, the file was missing on disk

Sorry for the runaround

Not sure if we need to keep it open. We run on this in staging scenarios (from local dev to online) with Drupal core version ^11 when caching gets enabled. If disabled no problem. But after re-enabling caching some css files cause this error, even if the files exist and have proper access permissions, cache flushes, cron runs. Further investigation required here from our side to evaluate but I would not close it to get more user reports just in case. Strange enough that it seems random which files get affected. Will try to find the reasons to come back on this.

I think we could commit the extra test coverage here even if there's no fix to commit as such.

If the test is added it would be on 11.x