## Problem/Motivation `Drupal\canvas\Asset\AssetResolver` extends core's `AssetResolver` and is registered as a decorator of `asset.resolver` in `canvas.services.yml`. Core changed the signature of the method Canvas overrides, so on current `11.x` the class can no longer be declared and PHP fatals: ``` PHP Fatal error: Declaration of Drupal\canvas\Asset\AssetResolver::getJsAssets( Drupal\Core\Asset\AttachedAssetsInterface $assets, $optimize, ?Drupal\Core\Language\LanguageInterface $language = null): array must be compatible with Drupal\Core\Asset\AssetResolver::getJsAssets( Drupal\Core\Asset\AttachedAssetsInterface $assets, $optimize, ?Drupal\Core\Language\LanguageInterface $language = null, bool $with_dependencies = true) in .../modules/contrib/canvas/src/Asset/AssetResolver.php on line 88 ``` The failure is at class-load time and does not depend on any Canvas feature being used, so it takes down every request that resolves assets and every test that loads the class. ### Root cause Core commit [`d9cc5091`][commit] (2026-08-04), from [#3565258 Support library-specific aggregates][core-issue], added a fourth parameter to **both** methods on `AssetResolverInterface` and its implementation: ```diff - public function getJsAssets(AttachedAssetsInterface $assets, $optimize, ?LanguageInterface $language = NULL); + public function getJsAssets(AttachedAssetsInterface $assets, $optimize, ?LanguageInterface $language = NULL, bool $with_dependencies = TRUE); - public function getCssAssets(AttachedAssetsInterface $assets, $optimize, ?LanguageInterface $language = NULL); + public function getCssAssets(AttachedAssetsInterface $assets, $optimize, ?LanguageInterface $language = NULL, bool $with_dependencies = TRUE); ``` Canvas overrides only `getJsAssets()`, so only that one fatals. `getCssAssets()` is inherited and unaffected. The commit exists on `11.x` only, so released cores are not affected. [commit]: https://git.drupalcode.org/project/drupal/-/commit/d9cc5091 [core-issue]: https://www.drupal.org/project/drupal/issues/3565258 ## Steps to reproduce 1. Install Canvas 1.9.0 against `drupal/core:11.x-dev`. 2. Run any test, or load any page that resolves assets. Reproduced in GitLab CI on an unrelated contrib module that depends on Canvas. Its `phpunit (next minor)` job installs `drupal/core 11.x-dev` and `drupal/canvas 1.9.0`, and reports **105 tests, 431 assertions, 23 errors** — every error the fatal above, in the tests that load the class. The same suite is green on 11.3 and 11.4. ## Proposed resolution Left to the maintainers. The constraints below interact in ways that are a judgement call about this codebase. Anything that fixes it has to hold across `core_version_requirement: ^11.3`, i.e. work against a three-parameter parent on 11.3/11.4 and a four-parameter parent on 11.x. Two things make that less trivial than it first looks: 1. **Runtime compatibility and static analysis pull in different directions.** PHP permits a child to declare optional parameters the parent lacks, and permits extra *positional* arguments to a userland method, so a single widened signature can satisfy all three core versions at runtime. But a `parent::getJsAssets()` call carrying four arguments is a *too many arguments* finding for any analyser resolving the parent against 11.3/11.4 — an IDE flagged it immediately when I tried it locally. Canvas's own PHPStan job may therefore go red on code that runs correctly, which may or may not be acceptable to you. 2. **`getCanvasJsAssets()` currently has nowhere to put the flag.** On the Canvas branch the method returns early, so whatever a caller asked for is not carried through. Core 11.x already calls the decorated service with `FALSE`: `JsAssetController::deliver()` does so when the aggregate URL carries a `?libraries=` query (`core/modules/system/src/Controller/JsAssetController.php` line 54), and `CssAssetController` does the same at line 64. That path looks unreachable for Canvas today, because it is only entered for a library-specific aggregate and no Canvas library declares the new `aggregate_target` key, which core defaults to `['js' => FALSE, 'css' => FALSE]` (`AssetResolver.php` lines 285 and 425). Whether that is a reason to ignore the flag, honor it, or document the gap is your call. ### One data point To check whether merely widening the signature is *runtime*-safe on the lower bound, I applied this locally and tested it — it is the smallest change that compiles against both parents: ```diff - public function getJsAssets(AttachedAssetsInterface $assets, $optimize, ?LanguageInterface $language = NULL): array { + public function getJsAssets(AttachedAssetsInterface $assets, $optimize, ?LanguageInterface $language = NULL, bool $with_dependencies = TRUE): array { ... - return parent::getJsAssets($assets, $optimize, $language); + return parent::getJsAssets($assets, $optimize, $language, $with_dependencies); ``` On **core 11.4.4 / PHP 8.4**, a contrib test suite exercising this decorator stayed green (105 tests, 606 assertions) and a page rendering 15 embedded components still returned HTTP 200 with its JS aggregate intact. Caveats, which is why this is not offered as the fix: not tested on 11.3, not tested on 11.x with the patch applied, does nothing about point 2, and trips the static analysis described in point 1. ## Remaining tasks - [ ] Decide the shape of the fix against the constraints above. - [ ] Decide whether `getCanvasJsAssets()` should honour `$with_dependencies`. - [ ] Add a test, or confirm the existing next-minor CI job covers it.