Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
When building a site using a different front controller than drupal/drupal, Drupal core's (drupal/core) dependencies that are needed for the test tools (Mink is needed by BrowserTestBase, for instance) are never installed, because they are part of core's require-dev packages instead of require. This is a bug, as those dependencies are not just needed for developing core, but also for other Drupal extensions.
Proposed resolution
In the future we may want to split off our test tools to a separate project we can pull in, but for now we can fix the problem by moving these dependencies from require-dev to require in ./core/composer.json.
Remaining tasks
None.
User interface changes
None.
API changes
None.
Data model changes
None.
Comments
Comment #2
klausiI don't think so - if you need BrowserTestBase then it means you are writing tests, so you need to copy core's require-dev section to your require-dev section. Your project outside of Drupal will not need BrowserTestBase for its actual production functionality, right?
Comment #3
XanoModules using core's test tools should not have to go through the effort of keeping up with core's 'dev' dependencies, as that would just be plain bad DX. As explained in the issue summary, ideally these tools would all be part of the same separate testing tools package, but they aren't now, so our options are limited.
Comment #4
larowlanI think until we have a separate testing process, keeping them in require-dev and needing to copy is the best option. Polluting the production autoloader/classmap with all the test-only classes would be counterproductive and bad for performance.
Comment #5
XanoSounds like we have another reason to finally get #2474007: Add a “General” project type to Drupal.org done.
Comment #6
klausiWhat you can do is publish a xano/drupal-testing meta package on packagist that is just a copy of core's require-dev section. That way any other project can just require-dev that without maintaining the copy of core's require-dev section. But not sure that is really worth it ...
Anyway, for core I think this is won't fix because test dependencies should not be on a production site, so they don't belong in the require section.
Comment #7
XanoIf testing tools do not belong in production code, should we fix #2474007: Add a “General” project type to Drupal.org, and then use this issue to move the code to a library? That would solve the problem for core, and let contrib simply pull in all of core's tools at once.
Comment #8
XanoI just ran into issues with a code base that required PHPUnit 5.3, but used core's base classes which throw a large number of method deprecation warnings when used with this PHPUnit version. Using the replacement methods in PHPUnit 5 is not possible, because these base classes come from core which uses (but does not technically require) PHPUnit 4. This is another example of how our test tool dependency management fails currently.
Comment #17
longwaveThis was solved by #3087626: Convert drupal/core-recommended & c. into a subtree split where we added the drupal/core-dev metapackage for development tools.