πŸ‡ΊπŸ‡ΈUnited States @markhalliwell

Account created on 5 May 2009, almost 16 years ago
#

Recent comments

πŸ‡ΊπŸ‡ΈUnited States markhalliwell

Note: this could and probably should be a separate issue, but I'd thought I'd raise my thoughts here for now.

Personally, I think the main problem is that we're not really using any of the JS_* groups anymore. Instead, we've been abusing it and placing everything in JS_LIBRARY by default (which, ironically, is not JS_DEFAULT).

From LibraryDiscoveryParser::buildByExtension():

// Unconditionally apply default groups for the defined asset files.
// The library system is a dependency management system. Each library
// properly specifies its dependencies instead of relying on a custom
// processing order.
if ($type == 'js') {
  $options['group'] = JS_LIBRARY;
}

This constant was chosen because of the "everything is now a library" movement that swept through core. While true, I think it's important to note that there should be a very clear distinction between what a "Drupal library" is and what a "Standalone JS library is" (outside of the Drupal-sphere).

This should have defaulted to JS_DEFAULT, not JS_LIBRARY.

True "libraries" (independent libraries that don't require other dependencies, like classList, domready, jQuery, underscore, etc.) are being grouped with the rest just because they're considered a "Drupal library" (which is a different concept).

Only these true libraries are the ones that should be in the JS_LIBRARY group IMO. This change alone would likely allow core to get away from arbitrary weights for these JS libraries.

We could even default to JS_LIBRARY at this point if the Drupal library doesn't specify any dependencies.

I'm sure all of this was done in an effort to reduce the number of aggregated bundles, but from what I've seen, even with this setup, we're still at a minimum of around 2-4 JS bundles depending on the site. Changing this to the above won't really affect this, but it would give clarity as to what is a "true library" and what isn't.

---

This all being said, I do think this issue is also important. Sometimes, one needs to be explicit as to "when" a library should be included. Having a mechanism that checks for a "before" and/or "after" dependency would be nice. Arbitrary "weights" are confusing and meaningless.

Production build 0.71.5 2024