Spike: Evaluate BLT fork compatibility with Symfony 7 / Robo 5 / Drupal 11

[ChadChandlerPS]

Background

vendor/acquia/blt/composer.json currently pins:

"drupal/core": "^10.0.0"
"symfony/console": "^6"
"symfony/config": "^6"
"symfony/filesystem": "^6"
"symfony/twig-bridge": "^6"
"consolidation/robo": "^4"

Drupal 11 requires Symfony 7, which conflicts with all four Symfony pins above and blocks any composer require drupal/core-recommended:^11 while BLT is present. Acquia archived upstream acquia/blt (EOL end of 2024) and confirmed no Drupal 11 support is planned.

We already maintain our own fork -- composer.json's repositories block points acquia/blt at github.com/nciocpl/blt rather than upstream - so we have a place to make and test these changes.

Question this spike answers

Can our BLT fork be updated to run on Symfony 7 + Robo 5 + Drupal 11, avoiding a full migration to Acquia CLI / Drupal Recommended Settings? Or does it surface blockers deep enough that the migration path is actually cheaper?

[ChadChandlerPS]

Verdict: Feasible. A patched nciocpl/blt fork runs Drupal 11.4, Symfony 7, Robo 5, and Drush 13 together — verified through real dependency resolution, a real Drush site install, and a real deploy-artifact build, not just a theoretical read of version constraints.

Methodology
Built a bare Drupal 11.4.5 site (drupal/recommended-project, no cgov_site profile) via ddev, pointed it at a locally patched branch of the BLT fork (spike/symfony7-robo5-drupal11) and iterated composer update → fix → retest until the dependency graph resolved, then exercised the actual BLT command surface used by this repo's CI and production deploy hook.

[ChadChandlerPS]

Composer changes required

Package | Before | After |

drupal/core (BLT's own require) | ^10.6.0 | ^11 | Why? = target version
symfony/config, console, filesystem, twig-bridge, yaml | ^6 | ^7 | Why? = Drupal 11 requirement
consolidation/robo | ^4 | ^5 | Why? = only Robo 5 accepts Symfony 7
drush/drush | ^12 | ^13 | Why? = Drupal 11 requirement
consolidation/config | ^2.0.0 | ^3.0 | Why? = 2.x never left Symfony 4-6; found mid-spike, capped the whole graph
doctrine/annotations | ^1.10.0 | ^2.0 | Why? = 1.x caps doctrine/lexer at 1.x, conflicts with Drupal 11.4's ~3.0.1

Also required in this repo's own composer.json (not BLT's): symfony/filesystem (^6.1→^7, used directly in scripts/composer/ScriptHandler.php), brianium/paratest (^6.3→^7), drupal/yaml_content (^1.0-alpha9→2.x-dev, no stable Drupal 11 release exists yet), drupal/responsive_favicons (^2.0→^4.0, two-major jump).

Note: There is a ticket to replace paratest with Drupal test.

[ChadChandlerPS]

Code changes required (the entire code-level LOE found)

// src/Robo/Application.php
- protected function doRunCommand(Command $command, InputInterface $input, OutputInterface $output) {
+ protected function doRunCommand(Command $command, InputInterface $input, OutputInterface $output): int {

// src/Robo/Hooks/InteractHook.php
- public function setInput(InputInterface $input) {
+ public function setInput(InputInterface $input): void {

- public function setOutput(OutputInterface $output) {
+ public function setOutput(OutputInterface $output): void {

Both are the same root cause: Symfony 7 / Robo 5 tightened return-type covariance enforcement on methods BLT overrides; the overrides, frozen since Acquia archived the repo, hadn't been updated to match.

[ChadChandlerPS]

BLT commands verified against the bare Drupal 11.4.5 site

Command

internal:add-to-project. = pass (after 2-line fix)
list = pass
setup = pass (full pipeline: composer install → git hooks → Drush 13 site-install → "Installation complete"
artifact:build = pass
drupal:update = pass
validate = ran the real Robo task; failed only on a missing docroot/modules/custom directory — a bare-site artifact, not a compatibility issue

The 15 custom cgov:* commands, cgov:rebuild-feq (theme-specific), cgov:install:site-sections, the MEO deploy hook's cgov:meo:db-update, and Cypress/Nightwatch runners — these read/write cgov_site-specific paths and content structures that don't exist without the real profile installed. Testing them means installing cgov_site for real, which is materially the full upgrade (contrib compatibility sweep across ~50 packages, core_version_requirement bumps across every custom module, resolving 3 known phpstan-deferred code risks, re-verifying 5 core patches) — not a narrower validation step. Recommend scoping that as its own ticket, not an extension of this one.