feat: #3620376 Require the vardot/swagger-ui library, so the recipe brings its own front-end library

Issue: #3620376

What

Require vardot/swagger-ui (^5.32.14) in this recipe's composer.json. One line, +2 −1.

Why

drupal/openapi_ui_swagger loads /libraries/swagger-ui/dist/swagger-ui-bundle.js, /libraries/swagger-ui/dist/swagger-ui-standalone-preset.js and /libraries/swagger-ui/dist/swagger-ui.css, and requires swagger-api/swagger-ui: ^3.0.17 || ^5.0. Upstream publishes that package as Composer type: library, not drupal-library, and composer/installers has no rule for a plain library — so it installs into vendor/swagger-api/swagger-ui, where nothing can serve it. The Varbase project worked around that by also fetching swagger-ui-dist from npm and copying it into web/libraries with a drupal-libraries-sync.js script, downloading the same library twice.

Two workarounds were tried and rejected:

• oomphinc/composer-installers-extender cannot place it: adding library to installer-types makes composer/installers claim every library-type package in the tree and abort with Package type "library" is not supported (measured).
• mnsami/composer-custom-directory-installer plus a per-package installer-paths entry does work, but puts an extra Composer plugin and a named path in every consuming project's composer.json. Rejected: a front-end library must arrive correctly out of the box.

vardot/swagger-ui (GitHub, Packagist) is a dist-only repackage of the same Swagger UI 5.32.14 distribution that declares type: drupal-library and:

"replace": { "swagger-api/swagger-ui": "self.version" }

Measured in a scratch project whose only installer path was the generic "web/libraries/{$name}": ["type:drupal-library"]:

• the files land at web/libraries/swagger-ui/dist/…, exactly where the module looks, with no plugin and no per-package path;
• vendor/swagger-api is absent — the replace satisfies drupal/openapi_ui_swagger's requirement, so the upstream package is never downloaded and the duplicate is gone.

Why the require belongs in this recipe, not in the project template

The replace only takes effect if something actually requires vardot/swagger-ui. A project that merely requires drupal/openapi_ui_swagger still resolves the upstream package into vendor/. This recipe is what installs the module, so it is what must require the library.

That matches the pattern the sibling recipes now follow, each recipe bringing the library its modules load: Varbase Admin Base requires vardot/jquery.fancytree, Varbase Content Base requires vardot/aos, Varbase Media Base requires vardot/dropzone, Varbase Editor Base requires vardot/ckeditor5-media-embed-drupal.

Wider context: part of moving Varbase 11 off the drupal-libraries-sync.js npm-copy script onto Composer drupal-library packages. Related issues: #3620350 (Varbase Project), #3620357 (Varbase Starter), #3620360 (Varbase Admin Base), #3620361 (Varbase Content Base), #3620362 (Varbase Editor Base), #3620363 (Varbase Media Base).

Verification

On a freshly installed Varbase 11.4.5 site in DDEV, all six libraries resolved from Packagist, with no plugin and no per-package installer paths in the root composer.json:

• 14 of 14 declared library files present;
• openapi_ui_swagger/swagger_ui resolves all 3 of its assets;
• vendor/swagger-api does not exist.

The project's own pipeline (build:composer-validate, validate:yaml-lint) was run locally with gitlab-ci-local on this branch: both jobs PASS.

AI-Generated: Yes

Checkpoints:

• File an issue
• Addition/Change/Update/Fix
• Testing to ensure no regression
• Automated unit testing coverage
• Automated functional testing coverage
• UX/UI designer responsibilities
• Readability
• Accessibility
• Performance
• Security
• Developer Documentation
• User Guide Documentation
• Reviewed by human
• Code review by maintainers
• Full testing and approval
• Credit contributors
• Review with the product owner
• Release notes snippet
• Release