- 🇳🇿New Zealand danielveza Brisbane, AU
This was fixed by #2905429: Library definitions containing only dependencies should be valid → . A library is only considered invalid now if it has none of the following keys:
- js
- css
- drupalSettings
- dependencies
Currently, every library has to have either js or css defined, otherwise it will result in IncompleteLibraryDefinitionException being thrown.
I think this a bit faulty since libraries can have dependencies and since D8 implements SMACSS approach many modules and themes are splitting their scripts and styles int smaller components that live as libraries on their own.
By this approach one can define a "base" library where all necessary components would be referenced as dependencies. Such "base" library does not necessarily need to define any JS or CSS. Its purpose is solely to bundle everything together.
This of course might not be a case for a theme's "base" library that could provide some global styling or scripts. But imagine a CSS framework(foundation, bootstrap,..) where everything is split into smaller parts and the "base" library is only referencing the smaller parts that make the framework's core. Yes, one can compile a big css/js core file for this instead of splitting the code into smaller parts, but that goes against the SMACSS principles. Yes, the developer could have a "base" library where he would list the main styles, scripts and core parts of the framework one by one, but that is semantically incorrect.
For example, if I have a foundation css framework in my theme I have libraries like:
- foundation/foundation.core
- foundation/foundation.abide
- foundation/foundation.accordion
- foundation/foundation.alert
- foundation/foundation.clearing
- foundation/foundation.dropdown
- foundation/foundation.equalizer
- foundation/foundation.interchange
- foundation/foundation.joyride
- foundation/foundation.magellan
- foundation/foundation.offcanvas
- foundation/foundation.orbit
- foundation/foundation.reveal
- foundation/foundation.slider
- foundation/foundation.tab
- foundation/foundation.tooltip
- foundation/foundation.topbar
Now let's say only the first four libraries makes the foundation's core, ie. they will be load on each page.
So instead of doing this:
base:
js:
- js/a.js: {}
- js/b.js: {}
- js/c.js: {}
css:
theme:
- css/theme/a.css
component:
- css/component/b.css: {}
- css/component/c.css: {}
- css/component/d.css: {}
dependencies:
- foundation/foundation.core
- foundation/foundation.abide
- foundation/foundation.accordion
- foundation/foundation.alert
I should be able to do this:
base:
js:
- js/a.js: {}
- js/b.js: {}
- js/c.js: {}
css:
theme:
- css/theme/a.css
component:
- css/component/b.css: {}
- css/component/c.css: {}
- css/component/d.css: {}
dependencies:
- mytheme/foundation
foundation:
dependencies:
- foundation/foundation.core
- foundation/foundation.abide
- foundation/foundation.accordion
- foundation/foundation.alert
Currently I have to provide empty css or js values(js: {} or css: {}) in order to prevent the exception being thrown.
So the solution for this is simply checking not if js or css keys are defined but also dependencies. This way we can bundle other libraries together into bundles without needing to define empty scripts/styles.
In retrospect I would even consider this as a bug.
Closed: outdated
10.1 ✨
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
This was fixed by #2905429: Library definitions containing only dependencies should be valid → . A library is only considered invalid now if it has none of the following keys: