Consider providing support for dependencies in "next major" tests
>>> [!note] Migrated issue
<!-- Drupal.org comment -->
<!-- Migrated from issue #3412308. -->
Reported by: [lostcarpark](https://www.drupal.org/user/346773)
Related to !101
>>>
<h3 id="summary-problem-motivation">Problem/Motivation</h3>
<p>Setting <code>OPT_IN_TEST_NEXT_MAJOR=1</code> is a great way of testing against the next Drupal version early.</p>
<p>However, if your module has dependencies, unless the dependent modules explicitly support Drupal 11 in composer.json and the module's .info.yml file, the build steps are likely to fail.</p>
<p>See also this Slack thread: <a href="https://drupal.slack.com/archives/CGKLP028K/p1704330116109669">https://drupal.slack.com/archives/CGKLP028K/p1704330116109669</a></p>
<h4 id="summary-steps-reproduce">Steps to reproduce</h4>
<p>Add <code>OPT_IN_TEST_NEXT_MAJOR=1</code> to the .gitlab-ci.yml file of a module with dependencies and run the pipeline.</p>
<p>"composer (next major)" step will fail with an error such as:</p>
<p><code>drupal/token_filter[2.0.0-rc1, ..., 2.x-dev] require drupal/core ^9.4 || ^10 -> satisfiable by drupal/core[9.4.0-alpha1, ..., 9.5.x-dev, 10.0.0-alpha1, ..., 10.2.x-dev].</code></p>
<h3 id="summary-proposed-resolution">Proposed resolution</h3>
<p>In my module, I was able to get past the build step by adding the following <code>before_script</code>:</p>
<pre>composer (next major):<br> before_script:<br> - composer global config --no-plugins allow-plugins.mglaman/composer-drupal-lenient true<br> - composer global require mglaman/composer-drupal-lenient<br> - composer config --merge --json extra.drupal-lenient.allowed-list '["drupal/token", "drupal/token_filter"]'</pre><p>In order to actually run the tests, I then needed to add the following:</p>
<pre>phpunit (next major):<br> before_script:<br> - grep -q "\^11" web/modules/contrib/token/token.info.yml || (grep -q "\^10" web/modules/contrib/token/token.info.yml && sed -i "s/\^10/\^10 \|\| ^11/" web/modules/contrib/token/token.info.yml)<br> - grep -q "\^11" web/modules/contrib/token_filter/token_filter.info.yml || (grep -q "\^10" web/modules/contrib/token_filter/token_filter.info.yml && sed -i "s/\^10/\^10 \|\| ^11/" web/modules/contrib/token_filter/token_filter.info.yml)</pre><p>One option would be to add a variable such as <code>$LENIENT-ALLOWLIST</code>, which could contain a list of modules that need to be enabled in Composer, and have info.yml files patched. Although modules could implement before_scripts such as above, it would seem to make sense to implement in a standard way, rather than having many modules implement the same pattern.</p>
<p>It would also be worth looking at ways patches could be applied to modules that have a fix for a future deprecation available, but not yet merged into their main branch.</p>
<h3 id="summary-remaining-tasks">Remaining tasks</h3>
<p>Choose best practice solution.</p>
<p>Update documentation.</p>
<h3 id="summary-ui-changes">User interface changes</h3>
<p>N/A</p>
<h3 id="summary-api-changes">API changes</h3>
<p>N/A</p>
<h3 id="summary-data-model-changes">Data model changes</h3>
<p>N/A</p>
issue