- Issue created by @m4TT3rs
- π¨π¦Canada gapple
At a quick glance, it looks like this could interfere with aggregation / optimization? I don't recall at the moment were the optimization step happens in the render flow.
- First commit to issue fork.
- last update
9 months ago 6 pass - Status changed to Needs review
9 months ago 8:46pm 15 April 2024 - last update
9 months ago 6 pass - πΊπΈUnited States neclimdul Houston, TX
Opened a merge request that applies a similar patch to both the CSS and JS rendering.
I'm also not sure hot the aggregation/optimization interacts with this but based on some basic testing the aggregation did not seem to be affected by this sorting. That's to say, by using weight to place an inline element between two aggregated scripts, they where split into two aggregation files served before and after the inline javascript.
- Status changed to Needs work
9 months ago 7:34pm 17 April 2024 - πΊπΈUnited States neclimdul Houston, TX
I didn't notice it in my initial review but with further testing I'm seeing some weirdness in javascript sorting. I think this might be causing problems with dependencies since they aren't being considered in the resort.
- πΊπΈUnited States neclimdul Houston, TX
Looked at this some. The asset rendering rendering pipeline is a mess and fights this at every step so I'm not even sure is going to work without updates to core. Some many things change in the sort depending on if its optimized or not. there's all the grouping. And each component relies on the logic of the other steps and assumes only internal and external files are possible.
Also found this that's probably related in some way. π Replace custom weights with dependencies in library declarations; introduce "before" and "after" for conditional ordering Needs work
Going to keep hacking on this but its pretty complicated and at the very least it can't really happen as late as the renderers.