JS aggregation returns 400 for libraries loaded in the header only as dependencies

Can we get the browser console errors in the issue summary instead of only in a video?

I can't reproduce this, neither on main nor on 11.4. But I've seen DDEV-specific caching issues in other contexts recently as well. People reported that a DDEV restart (or re-init?) fixed such stuff for them.

Does Drupal log anything?

I can confirm i get this issue on the main branch and on https://www.drupal.org/project/drupal/issues/3606571#comment-16719685
https://www.drupal.org/files/issues/2026-08-05/Screenshot%202026-08-05%2...

A good way of testing this issue is going to /admin/structure/menu. The chevrons are missing on the operations edit buttons and it throws a console error.

The error that it gives me when aggregation is on.

Uncaught ReferenceError: drupalSettings is not defined
    at js_1dF6Mh9GvTVkJTBBCP1paeYTVN-JV5zTEQdjl8ivqaY.js?scope=footer&language=en&theme=default_admin&libraries=eJxLzi9K1c_JT0zJKtZJBrFTikoLEnP0MkpyKwCbYwrR:4:1255
js_LnBtFYOj5NfP8x5BvJjY2zy-H9PFWvDUh_PL5byfn4M.js?scope=footer&language=en&theme=default_admin&libraries=eJxLykyPL8gsSNVPgjIAO9cGrg:2 Uncaught ReferenceError: drupalSettings is not defined
    at js_LnBtFYOj5NfP8x5BvJjY2zy-H9PFWvDUh_PL5byfn4M.js?scope=footer&language=en&theme=default_admin&libraries=eJxLykyPL8gsSNVPgjIAO9cGrg:2:1326
js_DM9n59Vhx1-DPvrJaRnVYqRlE-LKqJEKgXm0eDqBCFY.js?scope=footer&language=en&theme=default_admin&libraries=eJxLzs8rSa0oKU3M0U8pKi1IzNFLhovo5mTmZRfrJOcXpcIkE5NLMstSwRIo4gVF-elFqcXFAOCzHwI:2 Uncaught ReferenceError: drupalSettings is not defined
    at js_DM9n59Vhx1-DPvrJaRnVYqRlE-LKqJEKgXm0eDqBCFY.js?scope=footer&language=en&theme=default_admin&libraries=eJxLzs8rSa0oKU3M0U8pKi1IzNFLhovo5mTmZRfrJOcXpcIkE5NLMstSwRIo4gVF-elFqcXFAOCzHwI:2:6740
js_1e6PW4sXdKfOxbrajBZ45zGz02RUlQNHSYbJMfT50r0.js?scope=footer&language=en&theme=default_admin&libraries=eJxtzmEOgzAIBeALGT2SQcoMrqMMqJm3n4tb4hp_8vHyAIvRkKwq5B4WeHX4AZYgk52WZyXbxsqHf4OJXTMg_eER7bU4BxfpEt2g5hghPVgGQCSJpgVymS_o9MjPrehUI_baMwdMmYxciziv1JwkR1A6hmYlsPIMF296MN63NxSVa4o:2 Uncaught ReferenceError: drupalSettings is not defined
    at js_1e6PW4sXdKfOxbrajBZ45zGz02RUlQNHSYbJMfT50r0.js?scope=footer&language=en&theme=default_admin&libraries=eJxtzmEOgzAIBeALGT2SQcoMrqMMqJm3n4tb4hp_8vHyAIvRkKwq5B4WeHX4AZYgk52WZyXbxsqHf4OJXTMg_eER7bU4BxfpEt2g5hghPVgGQCSJpgVymS_o9MjPrehUI_baMwdMmYxciziv1JwkR1A6hmYlsPIMF296MN63NxSVa4o:2:19455
js_1jRH8QsOCn68JOJjtI6RyJOkufMvJ3cq56en7mVRq44.js?scope=footer&language=en&theme=default_admin&libraries=eJxLzi9K1U8pKi1IzAEAGfkEYQ:2 Uncaught TypeError: Drupal.displace is not a function
    at initDisplace (js_P4YdJzuKD82kzPDAsChRH0C1Dcckr1Jg7yleHAxsuto.js?scope=footer&language=en&theme=default_admin&libraries=eJxtyksKwEAIBNEL5XMmYcwgSLc4Mrl-ltm4rVeQbVPKiNtQmhC_RjIGXxxosEgvi9aCwa3Z2pJHz0oTTNf2-NsHW_I7GA:10:2115)
    at Array.forEach (<anonymous>)
    at Object.attach (js_P4YdJzuKD82kzPDAsChRH0C1Dcckr1Jg7yleHAxsuto.js?scope=footer&language=en&theme=default_admin&libraries=eJxtyksKwEAIBNEL5XMmYcwgSLc4Mrl-ltm4rVeQbVPKiNtQmhC_RjIGXxxosEgvi9aCwa3Z2pJHz0oTTNf2-NsHW_I7GA:10:2255)
    at js_1jRH8QsOCn68JOJjtI6RyJOkufMvJ3cq56en7mVRq44.js?scope=footer&language=en&theme=default_admin&libraries=eJxLzi9K1U8pKi1IzAEAGfkEYQ:2:427
    at Array.forEach (<anonymous>)
    at Drupal.attachBehaviors (js_1jRH8QsOCn68JOJjtI6RyJOkufMvJ3cq56en7mVRq44.js?scope=footer&language=en&theme=default_admin&libraries=eJxLzi9K1U8pKi1IzAEAGfkEYQ:2:353)
    at js_1jRH8QsOCn68JOJjtI6RyJOkufMvJ3cq56en7mVRq44.js?scope=footer&language=en&theme=default_admin&libraries=eJxLzi9K1U8pKi1IzAEAGfkEYQ:3:373
    at HTMLDocument.listener (js_1jRH8QsOCn68JOJjtI6RyJOkufMvJ3cq56en7mVRq44.js?scope=footer&language=en&theme=default_admin&libraries=eJxLzi9K1U8pKi1IzAEAGfkEYQ:3:161)

They are hashes, so not random. #3589208: Always use the file contents to determine asset aggregate filename hashes

You should experiment by disabling asset aggregation to verify that the asset system is the immediate problem.

Oh, you did say in the issue summary that disabling aggregation resolves this. Anyway, no, they are not random.

Disabling aggregation solves the issue i can confirm that.
It seems that specifically the Aggregate JavaScript files has the issue.
If i turn that off the chevrons come back and the site seems to work as expected.

Confirmed. I also missed the part about aggregation being part of the issue in the IS.

Now I can reproduce the issue as well when enabling JS aggregation. But only on main, not on 11.4

This is looking good. I've tested the failing scenario locally, and the bug is gone away.

I've reviewed the code in core/modules/system/src/Controller/JsAssetController.php and it looks correct, although I have to admit that I'm not an asset aggregation expert and don't know if this would have any unintended side-effects. But it looks as if it just closes a gap and that shouldn't cause any harm.

But I leave it at NR for others to also have a look.

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. 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.

Don't have time for an in-depth review today, but overall I think that the diagnosis is probably correct here but not overly keen on either of the suggested fixes, from the inline comment:

 // A 'libraries' query argument means the aggregate contains every JS
      // asset of the listed libraries, all in the same scope. Whether an asset
      // is resolved to the header or the footer depends on the full set of
      // libraries attached to the page it was rendered on: a library without
      // 'header: true' in its definition is still loaded in the header when a
      // header library depends on it. That page context is not available here,
      // so the resolved scope cannot be trusted. Use all resolved assets and
      // set the scope from the URL, restoring the render-time sort order so
      // the generated hash matches.

Given the asset will have all assets from all libraries, I think rather than forcing scope to be what's in the URL, we should ignore scope entirely and grab all the assets, which will mean we don't need to set scope in the URL at all. Should result in the same resulting file in the end and ought to be easier to follow.

When using the include/exclude pattern we'll still need to use scope in the URL, but once we have before/after fully implemented and weights deprecated/removed we should be able to remove includes/exclude entirely.

crosspost...

Pushed a commit for #26.

I didn't review the test coverage properly yet, however the new code passes the new test coverage. I did have to make one small change - the test looks for scope to determine header libraries but it won't always be there now. This may cause different test failures, but hopefully only test expectations rather than real ones..

Had a quick look at the tests. It mostly looked OK except for the filler content in the test file asset which claimed it needed to be there because web browsers skip compression under a certain length, removed it and the tests pass without it so I think that is probably Claude making things over complicated for no reason.

With the scope removed we can't absolutely be sure that the header js file being looked for is actually in the header (e.g. it could actually be in the footer instead), but we're really testing whether the header file produces a 400 response or not so I think that's probably OK? If not we'd have to parse the HTML to get URLs only before the body tag or similar. But we have more general test coverage that header files end up in the header I think.

I do get test failures running that test locally due to lack of brotli support in ddev's PHP but that's pre-existing and not affected by the MR. There's an open issue for it here but it's blocked on upstream https://github.com/ddev/ddev/issues/8549

This completely breaks js in default_admin so moving to critical.

2 comments on the MR.

Applied both of the suggestions because they looked reasonable, but now the tests are failing.

Found the issue. In core/lib/Drupal/Core/Asset/JsCollectionOptimizerLazy.php, this change

unset($query['include'], $query['exclude'], $query['delta'], $query['scope']);

was removing scope from the JS aggregrate URL query string, so changing it back to

unset($query['include'], $query['exclude'], $query['delta']);

fixed it.

I've confirmed in browser with standard install + default_admin that aggregated JS has no console errors.

Tests are green again, and test only fails as expected: https://git.drupalcode.org/project/drupal/-/jobs/11644653

It should be OK to remove the scope from the query string when libraries is set, because it's ignored now in that case.

Oh, OK, so maybe the issue is with the test.

    $header_dependency_aggregates = array_filter($script_urls, function (string $url): bool {
      $query = UrlHelper::parse($this->getAbsoluteUrl($url))['query'];
      if (($query['scope'] ?? NULL) !== 'header' || !isset($query['libraries'])) {
        return FALSE;
      }
      return str_contains(UrlHelper::uncompressQueryParameter($query['libraries']), 'core/drupal');
    });
    $this->assertNotEmpty($header_dependency_aggregates);

When I debugged, before adding the scope back to the query params, none of $script_urls contained a scope, so $header_dependency_aggregates ends up being empty. Do we need to do something like query the DOM to see if there are script tags in the <head> for the expected aggregated JS files?

See #31 I made the check a bit looser since we're really checking whether the header is a 400. Other tests check whether files end up in the header. If we parsed the script tags it would be better but not sure it's necessary to demonstrate the bug is fixed. Test only run should definitely fail.

OK, removed scope from query string again. Adjusted the test just to make sure there's one script URL that has core/drupal. Test only still fails as expected with 400: https://git.drupalcode.org/project/drupal/-/jobs/11647160

I only made a pretty minor test change, so I think I can commit this.

Committed and pushed 668d8be to main and e29fc19 to 11.x. Thanks!

@mherchel the issue that introduced this is only in 11.x, not 11.4: #3565258: Support library-specific aggregates