Remove the Varbase Dev Base requirement, as the recipe is never applied and its dev dependencies block install on Drupal CMS

Problem/Motivation

composer.json requires drupal/varbase_dev_base: 1.0.x-dev, but recipe.yml never lists varbase_dev_base in its recipes: list. The recipe is therefore never applied — the requirement only pulls its Composer dependencies into every install of this site template.

Varbase Dev Base describes itself as "A recipe to manage default development modules and configurations. Development Environment Modules, make sure to disable them in production." Its install: list is dblog, views_ui, config_update_ui, devel, sdc_devel, reroute_email.

Requiring it drags these into the dependency graph of a production site template:

• drupal/config_update, drupal/config_ignore
• drupal/devel, drupal/devel_entity_updates, drupal/sdc_devel
• drupal/stage_file_proxy, drupal/reroute_email
• drupal/storybook

Steps to reproduce

The drupal/storybook dependency makes this more than dead weight — it blocks installation on a stock Drupal CMS base:

mkdir my-drupal-site-ha1 && cd my-drupal-site-ha1
ddev config --project-type=drupal11 --docroot=web
ddev composer create-project drupal/cms
ddev composer config minimum-stability dev
ddev composer require drupal/horizonaid:1.0.x-dev

fails with:

Problem 1
  - Root composer.json requires drupal/horizonaid 1.0.x-dev
  - drupal/horizonaid 1.0.x-dev requires drupal/varbase_dev_base 1.0.x-dev
  - drupal/varbase_dev_base 1.0.x-dev requires drupal/storybook ~1.0
  - drupal/storybook[1.0.0, ..., 1.x-dev] require symfony/css-selector ^4 || ^6 || ^7
    -> the package is fixed to v8.1.6 (lock file version) by a partial update

Verified workarounds, none of which belong in a site builder's hands: add -W, delete composer.lock, or pin symfony/css-selector: ^7 in the root composer.json. With the lock removed, the tree resolves to symfony/css-selector v7.4.18 and installs fine — Drupal core 11.4.5 does not require css-selector at all, so stock Drupal CMS had simply drifted up to v8.1.6 with nothing holding it down.

Proposed resolution

Remove "drupal/varbase_dev_base": "1.0.x-dev" from composer.json. Nothing else changes: recipe.yml does not reference it, so no recipe, config or install behaviour is affected.

Anyone wanting the development tooling adds it deliberately on their own site:

composer require drupal/varbase_dev_base
drush recipe recipes/varbase_dev_base

That is the right place for a recipe whose own description says to disable its modules in production.

The same pattern exists in the sibling templates

Checked, not assumed — varbase_dev_base is required in composer.json and absent from recipe.yml in all three:

• Horizon Aid — this issue
• Educare
• Varbase Starter

Worth fixing in all three, and worth considering whether drupal/storybook should widen its symfony/css-selector constraint to include ^8 regardless, since that is what currently makes it incompatible with a Drupal CMS lock.

Remaining tasks

• ✅ File an issue
• ✅ Addition/Change/Update/Fix
• ✅ Testing to ensure no regression
• ➖ Automated unit/functional testing coverage
• ➖ Developer Documentation support
• ➖ User Guide Documentation support
• ➖ UX/UI designer responsibilities
• ➖ Accessibility and Readability
• ❌ Reviewed by a human
• ❌ Code review by maintainers
• ❌ Full testing and approval
• ❌ Credit contributors
• ❌ Review with the product owner
• ✅ Update Release Notes
• ✅ Release, horizonaid-1.0.0-alpha2

User interface changes

• None on a site built with this template, since the recipe was never applied. A developer who relied on the modules arriving in the codebase will need to require Varbase Dev Base explicitly.

API changes

• N/A

Data model changes

• N/A

Release notes snippet

• Remove the drupal/varbase_dev_base requirement. The recipe was never applied by this site template, and its development dependencies — devel, sdc_devel, stage_file_proxy, reroute_email, storybook — no longer install with a production site. Require it explicitly on development environments that want it.

AI-Generated: Yes