[PP-1]Add symfony/runtime dependency to core

Looks good to me, thanks!

I got to overhear the reasoning for #3313404: Use symfony/runtime for less bespoke bootstrap/compatibility with varied runtime environments earlier today and everything here convinces me this is worth the tradeoff of the additional dependency. Thanks @kingdutch!

Discussed with @alexpott. Having this dependency added separately from #3313404: Use symfony/runtime for less bespoke bootstrap/compatibility with varied runtime environments is a good separation of concerns; however, we don't want to end up in a situation where this dependency is added to a minor release without the functionality it unlocks. Since we're pretty close to alpha1 of 11.3 and we probably don't want to make a change as dramatic as #3313404: Use symfony/runtime for less bespoke bootstrap/compatibility with varied runtime environments in that release since it's so soon and it would not give us enough time for review and testing, we agreed to postpone this issue on 11.3.x being branched. Then potentially commit it to 11.x after that. I'm adding this issue to #3528698: [meta] Release preparation steps for 11.3.0 and 10.6.0 to keep track of it.

Thanks!

Tagging.

Since 11.3.x has been branch, I am setting this to active.

I agree this should be done separately, but think it should still be postponed until the concerns in the other issue are resolved.

I meant to set this to Active, so doing that now.

@nicxvan, can you elaborate on what you think this should be postponed on?

Yes there are two fairly divergent options in the related issue.

Now that both approaches have an mr demonstrating how they would work i have a bit less concern about this.

But I thought the dependency question should wait until an approach is decided upon. Both approaches use runtime so this is probably safe to move forward.

Although currently the two branches there are divergent if you check my comment then you'll see the next steps are to bring them very close to achieve znerol's most excellent appcontext idea with the only difference being how front controllers are written

So yeah this issue should go ahead the other issue will resolve hopefully soon

OK, then changing to Needs work to get the MR updated

This is now blocking #3453474: CLI entry point in Drupal Core (Dex) which is a strategic priority.

Given we have another use-case for it that doesn't involve a major rewrite of our front-controller like #3313404: Use symfony/runtime for less bespoke bootstrap/compatibility with varied runtime environments does - can we move forward with this?

The goal is to get #3453474: CLI entry point in Drupal Core (Dex) in before Drupal dev days to unlock the porting of other commands.

I'll reach out to RMs on slack

I'll take a look at the command issue, I'm interested if it looks like: #3576593: Create pre-bootstrap extension mechanism which still feels like the correct direction for the front controllers.

I rebased onto current main.

I ran COMPOSER_ROOT_VERSION=dev-main composer update drupal/core-recommended symfony/runtime, which added 8.0.8 to core-recommended. This was released on 2026.03.30 a couple of weeks after main was updated to Symfony 8. The prior release was 8.0.1 released in 2025.12.

I did a quick spot check by running ComposerIntegrationTest locally, which passed.

I updated the PHP version that is required by symfony/runtime to 8.4 since Symfony 8 was released.

Discussed with @catch and @longwave and have release manager approval. Also appears per #7 & #8 that @xjm also approved. Removing tag.

Rebased again since I think we are close to RTBC.

Test failures seem unrelated:

Drupal\Tests\config\Functional\ConfigInstallProfileOverrideTest::testInstallProfileConfigOverwrite
Error: Call to a member function label() on null

core/modules/config/tests/src/Functional/ConfigInstallProfileOverrideTest.php:141

Drupal\Tests\ckeditor5\FunctionalJavascript\CKEditor5Test::testLanguageOfPartsPlugin
Behat\Mink\Exception\ExpectationException: The string "The text format <em class="placeholder">ckeditor5</em> has been updated." was not found anywhere in the HTML response of the current page.

vendor/behat/mink/src/WebAssert.php:888
vendor/behat/mink/src/WebAssert.php:363
core/tests/Drupal/Tests/WebAssert.php:569
core/modules/ckeditor5/tests/src/FunctionalJavascript/CKEditor5Test.php:238
core/modules/ckeditor5/tests/src/FunctionalJavascript/CKEditor5Test.php:165

Rebased and the previous test failures disappeared. So we’re green if anyone wants to do another review of the issue summary and changes to RTBC?

Thanks, looks good to me. We are only adding the new dependency here, which is approved by release managers.

The approach that we discussed at DrupalCon Vienna 2025 was waiting for one of the issues that requires the dependency to be RTBC and ready for commit. Then, we would update this issue for the latest composer.lock etc., commit it, and then rebase the others for a smaller MR for final review there. (That way, the dependency does not sit unused in HEAD requiring dependency management while we're waiting for a usecase to maybe-land-maybe-not.)

Proper status is postponed to not clutter the queue; this will probably need to be rerolled against both main and 11.x once one or the other of the child issues is ready. It can be Re-TBCed then. Thanks everyone!