Because all script dependencies are/should be declared, the 'weight' key in library files declaration is now useless.
State of the patch:
Everything seems to be working
Was a problem with dependencies in contextual module
Needs testing :)
Comment | File | Size | Author |
---|---|---|---|
#97 | Screen Shot 2023-07-31 at 12.56.12 pm.png | 20.6 KB | acbramley |
Issue fork drupal-1945262
Show commands
Start 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:
Comments
Comment #1
nod_forgot tags
Comment #2
RobLoachYup.... Dependencies should determine asset order, not "weight".
Comment #3
Wim LeersThis broke at least two tricky edge cases:
drupalOverlayOpen
event is triggered andDrupal.behaviors.contextualToolbar.attach()
must already have been executed. The removal of the weights broke that. Note that we may not introduce a dependency here because contextual.toolbar.js does not depend on overlay-parent.js, but instead it listens to it in case it exists.I think the only way to solve this is by setting up the listener outside of the Drupal behaviors, so that it runs earlier. I hope I'm wrong :)
Comment #4
nod_Reroll.
Looks like contextual links work. Tour is still broken.
Comment #5
Wim LeersI had no idea what this issue was about — it's witty, but this is hopefully a bit more clear :)
Comment #6
nod_You're right, wasn't clean. Little small adjustment to make it easier on the eyes.
Comment #7
Wim LeersThis is blocked on a mechanism that uses a DAG (Directed Acyclic Graph) to determine the order of the assets. We can then work around the problem in #3 by having the ability to mark a library to be loaded before another one, and having the DAG take that into account.
(As per a call with sdboyer and a discussion with nod_.)
Related: #1014086-114: Stampedes and cold cache performance issues with css/js aggregation.
Comment #8
sunLet's revisit this — I think we were able to remove some of the weights in the libraries.yml patch already, but there are certainly lots of remaining instances.
Comment #9
YesCT CreditAttribution: YesCT commentedchanging to use the more common tag, so the less common one can be deleted, so it does not show up in the auto complete and confuse people.
Comment #10
Wim LeersIs #1805552: Remove custom weights from library definitions a duplicate of this?
Comment #11
nod_Reroll, There are two cases of conditional dependencies. I think the only problem could be with views-contextual but doesn't seems broken.
Anyway, last patch was before yml files so here it is.
Comment #12
RobLoachTested, clicked around Views. Works well.
Comment #13
webchickOh, nice! Less code, same functionality.
Committed and pushed to 8.0.x. Thanks!
Comment #15
catchCould someone cross-link the issue that actually removes weight support for js? I can't find it atm.
Comment #16
Wim LeersPlease revert this commit; it broke at least
/admin/config/development/testing
. Hence, this wasn't sufficiently manually tested. Is it possible that #12 only tested the JS in the Views module?Comment #18
webchickSorry about that! Sometimes my enthusiasm for a small RTBC queue gets the better of me. :) Reverted.
Comment #19
swentel CreditAttribution: swentel commentedyes, you can't filter and all checkboxes are gone ...
Comment #20
penyaskitoRemoved simpletest_js_alter(). Simpletest form works again.
Comment #21
penyaskitoAttachedAssetsTest::testAlter()
has a@see
forsimpletest_js_alter()
. We should do something about it if we remove it.Comment #22
penyaskitobtw, after this change the only
hook_alter_js()
implementation in core is locale :_)Comment #24
penyaskitosimpletest depends on drupal.tableselect, so I guess we should just remove the test.
Comment #25
penyaskitoDone that.
Comment #26
RobLoachRather than removing the test, it might be better to add a mock that tests the hook_js_alter() functionality. It's in core, and it should be tested.
Comment #27
penyaskitoNeeds work then.
Comment #28
RobLoachSomething like this? https://github.com/RobLoach/drupal/pull/4
Interdiff
Comment #29
RobLoachWrong file, sorry. Here's the correct patch.
Comment #32
penyaskito@RobLoach: Thanks for the test! I changed it so the module is only enabled for testAlter. I could have added a check for jquery in the test module, but this looks cleaner to me.
Comment #33
amol_tatkare CreditAttribution: amol_tatkare commentedI have tested the issue on views and test module. Patch #32 is working fine.
Please find attached screen shot.
Comment #34
amol_tatkare CreditAttribution: amol_tatkare commentedAdding Issue tag as #DCM2015. This patch was tested in Code Sprint.
Comment #35
penyaskitoComment #36
RobLoachElegant solution :-) . What other places should we manually test before this goes RTBC?
Comment #37
penyaskitoThere isn't any other hook_js_alter() but locale, and that one already fails in HEAD and is being worked on #2419897: Javascript translations are loaded in the wrong order due to missing dependencies.
So I guess we are good.
Aside of that, I don't know the *official* procedure for manually testing JS patches. IMHO there is no problem with RTBCing this one.
Comment #38
Wim LeersThis patch makes several comment lies. We either need to remove those comments by verifying that the ordering requirements that used to exist no longer apply, or we can't remove all weights just yet…
This comment is now a lie. And I'm afraid this means we'll have to keep this one for now.
Why can this simply be removed?
This comment says
simpletest.js
must run *before*tableselect.js
. But the library definition says the opposite:Which is it?
This comment is now also a lie.
Comment #39
penyaskitoThanks for the review @Wim!
I'm not sure how to proceed.
1. and 3.) I tested diverse cases of contextual links with different contextual items (nodes, blocks, views) + inline editing using the standard profile and found no errors. It worked as expected and they were included in the same order than previously. Maybe is just *luck*.
2) simpletest.js is included after tableselect.js, but it works as expected (which makes me ask: is *included* order the same than *executed* order? I guess yes and the order is not relevant anymore, but clarification would help).
How can we verify that the order is not relevant anymore? Git log and check the changes on the files?
In the meantime, while testing 2) I found a different problem. We have e.g testing groups Action and action, and clicking on the checkboxes has the desired behavior. But if we click on the labels, always the same group is checked/unchecked. The problem relies on having the same lowercased element id in both checkboxes. If we think about keeping the casing is works for my browser (Google Chrome), but we should not rely on that as per http://www.w3.org/TR/html401/struct/links.html#h-12.2.1 it is invalid to have the same id even with different casing.
I will create an issue for that tomorrow, too late here...
Comment #40
Wim Leers#39: manually tested both of these.
contextual.toolbar.js
must run aftercontextual.js
. But it does NOT depend oncontextual.js
: ifcontextual.js
hasn't run, then it short-circuits itself: if there are no contextual links on the page, thencontextual.js
won't have been loaded, and there is no need to show the corresponding toolbar tab (the pencil icon) in the toolbar.This need is discussed several times in #1762204: Introduce Assetic compatibility layer for core's internal handling of assets but apparently it doesn't have its own dedicated issue.
Due to lack of strong guarantees, I'm suggesting to keep this weight declaration in place for now. Until we have the ability to declare "before" and "after" relationships.
Exactly.
Also: oops, I was clearly confused. SimpleTest's JS depends on
tableselect.js
is equivalent with setting thetablselect.js
weight lower! My bad. So this change is actually fine already :) (Thathook_js_alter()
implementation should have been removed when it was converted into a library, but that was clearly forgotten.)contextual.js
.This case is similar to the one in point 1, but instead of needing an "after" relationship, this one needs a "before" relationship.
Therefore, I propose to remove the changes I quoted in #38.1 and #38.3. The rest we can keep. That brings down the total number of "weight" usages to *two*. That'll make actually removing it easier, and a follow-up issue to add support for "before" and after" simpler too.
Pinging catch for his thoughts on adding "before" and "after" besides only "dependencies" to asset library declarations.
Comment #41
nod_We can't do that, otherwise we end up with contextual.js before jquery, drupaljs and the rest and things crash. Need to remove all weights or none.
Wen we remove all the things, we can implement behavior order execution by extending #2367655: Control the list of behaviors run by Drupal.attachBehaviors and having something declared in the Drupal.behaviors objects.
Comment #42
nod_Comment #44
nod_I apologize about the whole "diet" part of the initial title and patch name, it was a poor attempt at wit. https://the-pastry-box-project.net/marc-drummond/2015-december-21
Comment #46
RobLoachControl lists being broken by Drupal.attachBehaviors is somewhat related to this, but doesn't have to block this from moving forwards. I'm going to re-open this, as as still have explicit weight definitions in our libraries.
Comment #47
Wim LeersComment #51
Wim LeersWithout #39 being addressed, this is impossible. We'll need not only
dependencies
, but alsobefore
andafter
.#2781577-17: Properly style outside-in off canvas tray lists yet another case where this is necessary; the only alternative right now is to implement hooks to alter weights. That example cannot specify
dependencies: ['classy/dialog']
, because then it'd depend on a particular theme to be loaded, which is not at all true. What it needs, isafter: ['classy/dialog']
.Comment #56
Wim LeersBecause this didn't happen, we now have #2905036: Lower weight of classList library to optimize aggregation :(
Let's get this going again!? :)
Comment #58
markhalliwellNote: 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 inJS_LIBRARY
by default (which, ironically, is notJS_DEFAULT
).From LibraryDiscoveryParser::buildByExtension():
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
, notJS_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 anydependencies
.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.
Comment #59
Berdir> we're still at a minimum of around 2-4 JS bundles depending on the site
I opened #2905036: Lower weight of classList library to optimize aggregation a while ago, which is a trivial change to save 1 additional aggregated JS file. That got pushed back due to a missing/unclear comment, I don't know how to really improve it to make it clearer, help welcome. This would IMHO be a nice performance improvement for everyone.
Comment #67
Wim LeersAnybody interested in taking this on? I can promise reviews 🤓
Comment #68
catchComment #70
Wim LeersThings are moving in core on this front! #2258313: Add license information to aggregated assets just landed and #3302755: On-the-fly JavaScript minification is now unblocked.
I'm hoping we can start pushing this forward too soonish, because it'll unblock #3232810: [PP-1] Allow setting aggregation groups for js files in library definitions, which is blocking #3224261: [PP-2] Front-end performance: concatenate CKEditor 5 JS assets for every unique configuration.
Comment #71
nod_Just looking at what fails if we remove the weights.
Added some before keys, they don't do anything yet.
Comment #72
nod_Comment #73
nod_with failing tests
Comment #74
nod_I guess the only way to go about this would be to leave the weights as-is because that might cause mayhem in contrib to remove them. even in core dependencies are not set properly and it's "hidden" by the weights.
anyway, trying to bring down failures as low as possible before putting the weights back.
For the before/after processing I was thinking of doing that in LibraryDependencyResolver but I don't want to add new dependencies if they don't already exist in the list of dependencies.
Comment #75
nod_bunch of failures left, probably missing dependency declaration.
For the before/after implementation i'm not sure at which level it makes the most sense to implement and I'm worried about circular "dependencies". At the very least I think that before/after should be a library-level key, not a file-specific key.
Comment #76
Wim LeersThis was exactly my fear 😬
I don't yet see how we can introduce this without breaking BC 😬 Maybe … just … maybe … this could work:
weight
s, but addbefore
+after
weight
sweight
s of non-core asset libraries with theweight
s of all assets in the tree of assets in that asset library'sdependencies
, and deducebefore
andafter
based on this⇒ this should in theory allow the asset library system to not rely on
weight
anymore, while still retaining BCThoughts? 🤓
Absolutely!
P.S.: nice, shockingly few failures when using just Drupal core! 🥳 Looks like it should be doable to get it down to zero?
P.P.S.: would be cool if eventually we'd test this patch against contrib modules that use
weight
s and have functional/functional JS test coverage as a way to validate the approach? 🤓Comment #77
nod_That should make all test pass beside the 2 new explicitly failing tests.
I like the plan, theorically it should be possible to do it like that.
Comment #79
catch#76 sounds like how we ought to do it. My only question is with #2 I would assume we'd want to blanket trigger deprecations when we find weight and remove any declarations from core in the first place.
Comment #80
Wim Leers#3303067: Compress aggregate URL query strings was committed last week — yay! Let's get this moving now? 🤓
Comment #81
Taran2LComment #82
Taran2LComment #84
needs-review-queue-bot CreditAttribution: needs-review-queue-bot as a volunteer commentedThe Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".
Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #86
Taran2Lhi @nod_, seems like rebase kinda "kills" notifications, sorry I've missed your comment. Added an explanation
MR removes all the weights throughout core, but before/after logic is still missing. However, as you can see all tests are passing, except the new one (before/after), and one that expected a specific weights (which are not there by the nature of the change)
Comment #87
nod_explanation is good, needs to be in comment inside the file
Comment #88
Taran2Laccomplished so far:
Comment #89
Taran2LAfaik, everything works as expected, but probably some manual testing is required
The one test that is failing checks whether jQueryUi assets have a specific weights, which is not true anymore. Thus, we need a decision what to do with it: remove or refactor to test whether everything is working properly rather than just checking weights.
A few places where weights are still in use:
1.
ckeditor5_js_alter()
- https://git.drupalcode.org/project/drupal/-/blob/10.1.x/core/modules/cke...Not sure what exactly Drupal tries to achieve here, someone else needs to take a look
2.
AttachedAssetsTest::testAlter()
- https://git.drupalcode.org/project/drupal/-/blob/10.1.x/core/tests/Drupa...Tests altering weight via a hook, but this should not be a case anymore. Remove?
3.
settings_tray.theme.css
- https://git.drupalcode.org/project/drupal/-/blob/10.1.x/core/modules/set...There is a mention of this issue, but a lot of things have changed since it has been added (not sure it is relevant anymore)
Next steps (imo)
1. Refactor existing library discovery to use different key for specifying an asset level (?) (btw, what should be the naming here?) - (can be a follow-up issue)
2. Deprecate usage of weight key with a deprecation message (can be a follow-up issue)
Comment #90
nod_Excellent, had a quick look and I like what I see :)
One question is how does it work when a library that has a before/after is added but the library it should be loaded before/after is not added to the page at the same time?
Comment #91
Wim LeersYay, #3222107: Library order asset weights do not work properly when a large number of javascript files is loaded between two jQuery UI libraries landed, which means we'll be able to make this change with more confidence! 😊
Comment #92
larowlanIs there an option to just use native es6 imports and type=module and just let the browser sort this out now we don't have to support IE
Comment #93
Taran2LSo, in short, it collects all needed libraries first (pass one), and only after that (with the full list) it adds before/after logic (pass two)
Comment #94
Taran2LSetting this to NR, as some guidance needs for the next steps, see #89
Comment #95
smustgrave CreditAttribution: smustgrave at Mobomo commentedMoving to NW for the issue summary update
And failure in MR seems to be legit to the issue at hand.
Comment #97
acbramley CreditAttribution: acbramley at PreviousNext for Service NSW commentedWas hoping this would fix an issue I'm having with Paragraphs Library and Entity embed. For some reason in the final Entity embed modal while adding a paragraph library item, jquery ui's dialog button styling is overriding Claro's leading to some pretty ugly buttons:
This does not happen when embedding an entity in a paragraph on a node form, only via Paragraphs Library (i.e /admin/content/paragraphs/add/default)
Unfortunately the MR doesn't solve this particular issue.
EDIT: Further debugging - it seems like
/core/themes/claro/css/components/jquery.ui/theme.css
is being added multiple times to the page. Once when the page loads, once when I add a paragraph, and then again when I open the embed modal so that would explain why styles are getting overwritten.Comment #98
Taran2L@acbramley, well, this is good to be honest, as this issue is pure DX change, i.e. it should not fix anything (yeah, maybe, accidentally)
Comment #99
acbramley CreditAttribution: acbramley at PreviousNext for Service NSW commented@Taran2L no worries - this was a red herring anyway. My issue - #3378341: claro.jquery.ui css assets may be added the page multiple times