- ๐ฌ๐งUnited Kingdom catch
Discussed this a bit with @nod_ in slack.
I think we can do this without the dependency issue having landed. We need to make a new aggregate every time we encounter a new group, but it shouldn't affect the actual order of assets, just whether they're in a new aggregate or not.
Also I'm wondering if we should add a new key to library definitions like 'unique aggregate' instead of using group directly, this would work the same as 'preprocess: false' but at the library level. We could use it for jQuery and ckeditor, which are already setting preprocess: false on their individual files (after ๐ By default, don't aggregate jquery.js Active . But we could also set it for:
- other libraries with large individual files
- other libraries with lots of files that would add up to a decent sized aggregate, internal.jquery_ui would be a good example.There is a risk that contrib overuses it, but it can't do any more damage, or actually less, than setting preprocess: false.
The problem with groupings bigger than one library is that as soon as libraries vary between pages, it's almost impossible to prevent duplication again
e.g. if library A and library B depend on library C, but library A, B and C can all be independently added to a page, then a page can have:
A
AB
ABC
ACI tried to come up with an approach for that problem in ๐ Aggregate 'only ancestor' libraries in their own groups Active and while it worked in theory, it completely failed in practice. e.g. if we only aggregate 'A'-type libraries together, we can still have multiple libraries like A that can result in duplicates, and the same for B and C.
However if we selectively aggregate a handful of libraries independently, then they're never combined with anything else and can't create duplicates. The libraries that are still aggregated together can still create duplicates, but the duplicates will be smaller because they don't include the ones we're aggregating by themselves.