Library definitions containing only dependencies should be valid

+1! I think this makes sense. We should also get @nod_'s thoughts though. I think we've considered this before at some point.

+++ b/core/tests/Drupal/Tests/Core/Asset/library_test_files/example_module_only_dependencies.libraries.yml
@@ -0,0 +1,2 @@
+example:
+  dependencies: {  }

Well but this asset library does seem rather nonsensical, doesn't it? Shouldn't it at least have some dependency?

Can you provide an example of why this would be useful?

+1. I ran into this today. Use case is:

- I have a library definition for each layout, e.g. one for a 50% / 50%, another for 75% 25%, etc.
- I also have a library definition that loads ALL of them, instead of having to do attach_library() 20 times if you need them all (you might).

layouts.all:
  dependencies:
    - layout_1
    - layout_2
    - layout_3
    - etc...

Results in one {{ attach_library('lala/layouts.all') }}, being possible vs...

{{ attach_library('lala/layouts.layout_1') }}
{{ attach_library('lala/layouts.layout_2') }}
{{ attach_library('lala/layouts.layout_3') }}, etc.

Thanks!

Does this need a change record?

Yeah, a small change record would be good. Otherwise this looks fine to me.

This would be useful. For now adding the js: { } does prevent the exception.

My use case: Packaging up a collection of libraries into a single, meta library is a code and complexity reduction in my codebase. It doesn't necessarily need to add any files or settings of its own to be useful.

I came across this issue when we were working on #2926155: Follow-up to #2809427: update from jQuery UI 1.11.4 to 1.12.1 forgot to list some new JS files in *.libraries.yml
One idea in that issue for de-tangling the dependencies of jQuery UI was to pull each dependent file out to its own asset library which could be selectively required by the other jQuery UI asset libraries. A single "collection" of these other smaller libraries would have been a convenient solution for maintaining BC while the actual files were shuffled around.

It looks like this issue just needed a change record and a re-roll for the patch (although it was still green). I ran the LibraryDiscoveryParserTest and tested this manually by creating a jQuery UI asset library that only depended on another new asset library.

Another use case for this:
in 3067251 # 49
@xjm discussed an approach for a contrib module that would be just a dependency.

we could retain the contrib module, but just have it declare a dependency on the core library

A contrib module could act as a placeholder for a soon-to-be-deprecated core library.
Modules could depend on a contrib asset library which in turn depends on a core asset library.
Once that core asset library is removed, the contrib library could provide the files instead, and the modules' dependency would be unchanged.

+++ b/core/tests/Drupal/Tests/Core/Asset/LibraryDiscoveryParserTest.php
@@ -171,6 +171,25 @@ public function testInvalidLibrariesFile() {
+   * Tests that an exception is thrown when no CSS/JS/setting is specified.

Shouldn't this be Tests that no exception is thrown 🤔

Shouldn't this be "Tests that no exception is thrown"

That's correct, the other tests in this suite all expectException while this new test checks that no exception is thrown.
I also changed the wording of the testBuildByExtensionWithMissingInformation comment since it didn't mention dependencies in the missing info it's checking.

Perfect :)

Note this is perfectly cherry-pickable to 8.8.x — no disruption.

Committed a80a479 and pushed to 9.0.x then cherry-picked back to 8.9.x and 8.8.x. Thanks!

Libraries may contain only other libraries as dependencies

I was a bit confused by the title of this change record. At first glance it read that libraries may contain only other libraries, which didn't make sense. Can I suggest:

Libraries may contain other libraries as dependencies