Skip to content

Settle the loose ends from the backend rename #899

Description

@AlexSkrypnyk

Summary

#896 renames the Drupal, Drush and Blackbox drivers to backends, and its description flags 4 calls under "Worth a second look". None of them blocks that PR, but each is either a decision someone may want to reverse or a gap the rename exposed, so they're collected here instead of fading out with a merged PR's description.

2 of them most likely need nothing more than a yes: the removed SubDriverFinderInterface and the renamed test-only names. 1 is a judgment call on how loudly old container names should fail. The last is a real gap: nothing checks import order, and the rename shows what that costs.

Details

1. SubDriverFinderInterface is removed, not renamed

#896 deletes SubDriverFinderInterface and DrupalDriver::getSubDriverPaths() instead of renaming them. They came in with the driver layer in #776 to serve the Drupal Extension's subcontext discovery, which this package doesn't do, and nothing in src/ called them. The method only bootstrapped Drupal and returned getCore()->getExtensionPathList(), and MIGRATION.md now points there directly. backendFor() bootstraps whatever it resolves, so the result is the same list:

$paths = $this->backendFor(CoreCapabilityInterface::class)->getCore()->getExtensionPathList();

Renaming it to SubBackendFinderInterface::getSubBackendPaths() would have named a concept that doesn't exist here.

Recommendation: keep the removal.

2. Test-only names follow the vocabulary too

#896 also renames names only the test suite sees:

  • The driver_field_test fixture module is backend_field_test in both the d11 and d12 fixture sites, and its field types are backend_test_scalar and backend_test_reference.
  • The harness steps read a configuration listing the backend(s) :backends, the scenario backend order should be :order and the :capability capability should resolve to the :expected backend.
  • driver.feature and driver_feature_tag.feature are backend.feature and backend_feature_tag.feature.

None of these is public, so they could have kept "driver", but then the test suite would carry the exact collision the rename removes from src. The "Backend, browser driver and HTTP client" section of CONTRIBUTING.md already says no name this package owns uses "driver" for anything but Mink's, and a fixture module is a name this package owns.

Recommendation: keep them. If test-only names should be exempt instead, that exemption belongs in the same CONTRIBUTING.md section.

3. Old service IDs and *.class parameters fail quietly

An old drivers key fails the container build in BehatStepsExtension::rejectRenamedKeys(), and an old @driver: tag fails its scenario at the start in BackendListener, each with a message naming its replacement. The service IDs and container parameters moved as well (behat_steps.driver_registry.class is now behat_steps.backend_registry.class, behat_steps.driver.drush.binary is now behat_steps.backend.drush.binary, and so on), but nothing looks for the old ones:

  • A parameter under its old name is never read, so an implementation swapped in through it quietly stops being used.
  • A reference to an old service ID fails with Symfony's own missing-service error rather than one that explains the rename.

MIGRATION.md warns about both. Only a consumer's own extension or compiler pass can touch these names, and no 4.x release has been tagged yet, so the only installs that could be carrying them run dev-4.x.

Options:

  1. Leave it to MIGRATION.md.
  2. Add a compiler pass that fails on any behat_steps.driver* parameter or service ID and names the behat_steps.backend* one that replaced it.

Recommendation: option 1, unless a known dev-4.x consumer swaps an implementation this way.

4. Nothing checks import order

#896 moved each renamed Backend import above the Behat ones by hand, following whatever order its file already used. 7 test files still list Backend imports below Behat ones:

  • tests/behat/bootstrap/BehatCliTrait.php, inside the heredoc that writes the nested run's context
  • tests/phpunit/src/Kernel/Helper/Drupal/EntityLifecycleTraitVocabularyKernelTest.php
  • tests/phpunit/src/Unit/Behat/Listener/BackendListenerTest.php
  • tests/phpunit/src/Unit/Behat/Manager/AuthenticatorTest.php
  • tests/phpunit/src/Unit/Behat/Manager/BackendRegistryTest.php
  • tests/phpunit/src/Unit/Behat/Prerequisite/PrerequisiteReaderTest.php
  • tests/phpunit/src/Unit/Behat/ServiceContainer/BackendPassTest.php

Lint passed anyway, because neither phpcs.xml nor the Drupal and DrevOps standards it includes check the order of use statements. The files don't agree on one either. Of the 300 PHP files under src, tests/phpunit/src, tests/behat/bootstrap and scripts, plus docs.php, that import 2 or more names:

Files Order
268 Sorted, with no pair where the rules below disagree
12 Case-insensitive, by namespace segment (Behat\Mink\Driver before Behat\MinkExtension)
8 Raw bytes or case-sensitive (Drupal\KernelTests before Drupal\block)
12 Out of order under every rule, including the 7 above

Slevomat's AlphabeticallySortedUses sniff is already installed under vendor/slevomat/coding-standard. It compares namespaces segment by segment, case-insensitively by default, which is the order the 268 and the 12 already follow, and it can fix everything it flags.

Recommendation: enable it at its default setting and let ahoy lint-fix reorder the rest, roughly 20 files. A sniff only reads real use statements, so the BehatCliTrait.php heredoc still needs fixing by hand.

Tasks

  • Confirm the removal of SubDriverFinderInterface, or bring it back under a backend name.
  • Confirm test-only names follow the vocabulary, or write the exemption into CONTRIBUTING.md.
  • Decide whether old behat_steps.driver* parameters and service IDs should fail the build, and add the compiler pass with a unit test if so.
  • Enable SlevomatCodingStandard.Namespaces.AlphabeticallySortedUses in phpcs.xml, run ahoy lint-fix, and reorder the BehatCliTrait.php heredoc by hand.

Builds on #896, so it should start once that merges.

Activity

  1. added this to the 4.0 milestone on Oct 2, 2026
  2. added a commit that references this issue on Oct 2, 2026
  3. AlexSkrypnyk commented on Oct 2, 2026

    @AlexSkrypnyk
    MemberAuthor

    Implemented in #903, merged into 4.x.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions