Now that #3565258: Support library-specific aggregates and #1945262: Introduce "before" and "after" for conditional ordering in library definitions have landed we should have more opportunities to improve aggregate hit rates.
Since Olivero and Claro are on their way out of core and default_admin's libraries are still in flux, concentrating on CSS shipped with core modules.
| Comment | File | Size | Author |
|---|
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #5
catchComment #6
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #7
catchRebased.
Comment #8
smustgrave commentedThis should work as not sure how often the navigation css changes so this shouldn't randomly break :)
Comment #9
catchComment #10
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #11
catchRebased.
Comment #12
berdirChecking this in \Drupal\Core\Asset\CssCollectionGrouper::group, I noticed this causes two separate libraries for navigation to be loaded, first it's all the base category libraries like internal.tooltip, between normalize and system.base. And then later on it is internal.navigation, which uses the theme category. not a big deal, but I'm still confused as to why you'd want to use those css categories, now that we have explicit dependencies. Does it make sense to normalize all these navigation libraries to use the same category? which one? are modules supposed to use "theme", as they are not, in fact, a theme?
Also, this only sets the css aggregate key and not js, is there a reason for this?
The issue summary doesn't say anything about navigation module, just not-themes, seems like this had a possibly wider scope once?
Tagging for needs issue summary update and setting back to needs review at least.
Comment #13
catchAgreed with these questions, but I think we need a front end/CSS person for the answers, which I am not. There's an issue around somewhere to use native CSS layers instead of groups, which would definitely mean we could remove them altogether, but that'd be a big refactor of everything probably.
I split this out of an issue specifically for CSS, but now its on its own, we could add the js libraries in I think - marking needs work for that at least.