- Issue created by @catch
- 🇬🇧United Kingdom catch
Roughly what I think we need to reproduce the problem in the other issue, I still haven't gone through to figure out exactly what combination of libraries is causing it (there's a lot in real life).
The overall issue appears to be this:
1. There are lots of libraries on the node/add page in general with various dependencies, while they're attached to the page in whatever order, many of them don't have explicit dependencies on each other so could be in any order.
2. When we send the list of libraries to the aggregate URL, this is the 'minimal representative set' - i.e. a shorter list of libraries with libraries that are dependencies of other ones we're removing absent from the list.
3. When we put those dependent libraries back into the list, the resulting order is different.
The fix in 🐛 Aggregation URL hashes should be built from normalized list of libraries Fixed converts the arbitrary list of libraries sent to AssetResolver::getLibrariesToLoad() to the minimal representative set, before then expanding it out again to the full list of dependencies. This fixes the aggregation bug on there.
Ideally we want a test that fails with that issue reverted, but also to see if we can guarantee that given any combination of libraries resulting in the same resolved set, that the resultant list is in the same order regardless of what is passed in. It's possible that the minimal representative trick is doing this, but if not we should find something that does. This will improve hit rates for aggregates across a site too.