Problem/Motivation

composer.json on 1.0.x pins 19 of its 35 requires to 1.0.x-dev, including every Varbase base recipe and the theme:

drupal/varbase_admin_base: 1.0.x-dev
drupal/varbase_users_base: 1.0.x-dev
drupal/varbase_dev_base: 1.0.x-dev
drupal/varbase_security_base: 1.0.x-dev
drupal/varbase_performance_base: 1.0.x-dev
drupal/varbase_media_base: 1.0.x-dev
drupal/varbase_editor_base: 1.0.x-dev
drupal/varbase_content_base: 1.0.x-dev
drupal/varbase_workflow_base: 1.0.x-dev
drupal/varbase_i18n_base: 1.0.x-dev
drupal/varbase_seo_base: 1.0.x-dev
drupal/varbase_ai_base: 1.0.x-dev
drupal/varbase_api_base: 1.0.x-dev
drupal/varbase_webform_base: 1.0.x-dev
drupal/varbase_auth_base: 1.0.x-dev
drupal/varbase_page_base: 1.0.x-dev
drupal/varbase_blog_base: 1.0.x-dev
drupal/varbase_demo_content: 1.0.x-dev
drupal/vartheme_bs5_rightup: 1.0.x-dev

Two consequences.

It does not install on a build that already has the releases. Those base recipes have real releases (Varbase Admin Base is at 1.0.0-rc1), so a normal composer require drupal/rightup onto a Varbase 11 codebase fails:

Problem 1
  - Root composer.json requires drupal/rightup 1.0.x-dev -> satisfiable by drupal/rightup[1.0.x-dev].
  - drupal/rightup 1.0.x-dev requires drupal/varbase_admin_base 1.0.x-dev -> found
    drupal/varbase_admin_base[1.0.x-dev] but the package is fixed to 1.0.0-rc1
    (lock file version) by a partial update and that version does not match.

It installs only with --with-all-dependencies, which then drags all 19 packages off their releases and onto their dev branches for the whole site, not just for RightUp.

It cannot be released. A tagged release of RightUp requiring 1.0.x-dev of 19 packages is not installable by anyone following the normal Varbase install path, so this blocks the first RightUp release regardless of the template's own readiness.

Steps to reproduce

  1. Build a Varbase 11 codebase the normal way, so the base recipes resolve to their releases.
  2. ddev composer require drupal/rightup:1.0.x-dev
  3. It fails with the conflict above. Adding -W succeeds but moves 19 packages to their dev branches.

Proposed resolution

Use release constraints, the way Educare already does. Educare has zero dev-pinned requires and asks for drupal/varbase_admin_base: ~1.0.0, which resolves cleanly against both the rc and any later release.

Dev pins are reasonable while a template is being bootstrapped and every base recipe is moving under it. RightUp is past that point for most of them: the base recipes it depends on have releases.

This is not RightUp only

Horizon Aid carries the identical 19 dev pins on its 1.0.x. Educare is the only one of the three on release constraints. Worth deciding the convention once and applying it to both; happy to file the Horizon Aid twin if that is wanted.

How this was found

While building a RightUp site to verify the Canvas Icon Picker work (#3620072). The workspace builder appeared to succeed but had silently skipped the package, because its composer require hit exactly this conflict and the failure was not surfaced. That is a workspace tooling problem rather than a RightUp one, but the root cause is here.

Reported with AI assistance (AI-Generated: Yes), per the Drupal AI policy. Every claim above was verified by running it.

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

User interface changes

  • N/A

API changes

  • N/A

Data model changes

  • Dependency constraints only. No config or content changes.

Release notes snippet

  • RightUp now depends on released versions of the Varbase base recipes rather than their development branches, so it installs on a standard Varbase 11 codebase without forcing dev versions across the site.

Comments

rajab natshah created an issue.

rajab natshah’s picture

rajab natshah
he/him
commented

Data on this from a build today, in case it is useful. Tested on the dev project template, drupal/varbase_project:11.0.x-dev, Drupal 11.4.6.

All three routes, in order:

1. Bare require on a fresh lock. Fails, exit 2.

ddev composer create-project "drupal/varbase_project:11.0.x-dev"
ddev composer require drupal/rightup:1.0.x-dev

- drupal/rightup 1.0.x-dev requires drupal/varbase_recipes 1.0.x-dev -> found
  drupal/varbase_recipes[dev-1.0.x, 1.0.x-dev (alias of dev-1.0.x)] but the package is
  fixed to 1.0.0-beta4 (lock file version) by a partial update and that version does not match.

2. ddev composer update first, then require. Still fails, exit 2, and the conflict simply moves to the next pinned package:

- drupal/rightup 1.0.x-dev requires drupal/varbase_admin_base 1.0.x-dev -> found
  drupal/varbase_admin_base[1.0.x-dev] but the package is fixed to 1.0.0-rc4 (lock file version)

3. -W. Exit 0.

ddev composer require drupal/rightup:1.0.x-dev -W

So composer update is not a workaround for this, which is worth recording because it looks like one. It does not move varbase_recipes off 1.0.0-beta4: nothing in varbase_project asks for a dev version, so beta4 satisfies its constraints and the update leaves it alone. The recipe pins twenty-odd packages to 1.0.x-dev while the project template's committed lock pins releases, so the conflict is inherent and walks from one package to the next as each is unblocked.

One thing that has changed the shape of it: canonical 1.0.x now requires drupal/varbase_recipes: 1.0.x-dev directly, since #3620072. Before that the requirement arrived transitively through varbase_admin_base, so the first error names varbase_recipes rather than varbase_admin_base.

Separately, the 11.0.x-dev template does clear the drimage_improved patch failure that the released template hit, because its lock carries vardot/varbase-patches 11.0.x-dev rather than 11.0.38. Zero patch failures on the build. That is a different problem from this one, though, and it does not help the resolve.