AssetResolver::getCssAssets() should not try to sort and optimise if $css is empty.

Redo of #5 to see if this still happens.

I wonder if this is purely happening when there's only a library or two to load, and the library only contains JavaScript - we don't know whether we need CSS or not until the library definitions have been parsed.

If that's the case, we can skip the sort and optimize, and cache the empty array.

And here's what the fix should look like. Not really a bug IMO but saves a bit of work.

#24 shows we have all sorts of test coverage hitting this, so no need to add more, change makes sense.

Updated the title to match the fix, we are not returning early because we want the cache to be set.

Checking RTBC issues. There are no unanswered questions here or other work to do. I did not review the change itself.

Committed and pushed dc39dd56b6c to 11.x and e8961de11a5 to 10.1.x. Thanks!

For future googlers: the symptom that led me to this thread was "Exception: Invalid CSS asset type" error in dblogs.

Exception: Invalid CSS asset type. in Drupal\Core\Asset\CssCollectionRenderer->render() (line 82 of core/lib/Drupal/Core/Asset/CssCollectionRenderer.php).

patch in #25 fixed it.

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

I'm quite sure we should have committed my exception from #5, lol

+    // This is likely an AJAX request, return early.
+    if (empty($css)) {
+      throw new \Exception('This should not ever happen, wonder if test produce this helvetica scenario.');
+    }
+

For the uninitiated https://www.youtube.com/watch?v=-Y-yKmzP-4U