Install the front-end libraries with Composer, not drupal-libraries-sync

Problem/Motivation

Varbase 11 used to get six front-end libraries by running scripts/drupal-libraries-sync.js, a Node script that copied files out of node_modules/ into web/libraries/, driven by a drupal-libraries block plus six npm dependencies and a postinstall hook in package.json. That is replaced by Composer packages on Packagist, each required by the module or the varbase_* recipe that actually loads it: vardot/aos 2.3.4, vardot/jquery.fancytree 2.38.5, vardot/ckeditor5-media-embed-drupal 47.6.2, vardot/ace 1.44.0 and vardot/dropzone 5.9.3 (all type: drupal-library, all on Packagist), plus swagger-api/swagger-ui, which drupal/openapi_ui_swagger already required and which only needed an installer path.

Horizon Aid is the only one of the Vardot site templates whose wiring for this script is still live. It carries scripts/drupal-libraries-sync.js and scripts/assets/drupal-libraries.package.json (which exists only to feed that sync), and the Drupal CMS pre-test job in .gitlab-ci.yml writes that package.json into the built site, copies the script in beside it, and runs yarn install so the postinstall hook fires. With the libraries now coming from Composer, that whole path is obsolete.

The same job also asserted the wiring by counting entries in the drupal-libraries block of a package.json. A count can pass while an installer path is wrong or an upstream package layout has changed, so it does not actually prove the assets the components load are on disk.

Steps to reproduce

1. Check out the 1.0.x branch.
2. git grep -n drupal-libraries-sync 1.0.x — hits in .gitlab-ci.yml, in scripts/assets/drupal-libraries.package.json and the script itself.
3. Read the Drupal CMS pre-test job in .gitlab-ci.yml: it copies scripts/assets/drupal-libraries.package.json to package.json, writes a .yarnrc.yml forcing nodeLinker: node-modules, copies the sync script in and runs corepack yarn install.
4. Note the assertion that follows: it counts the entries of the drupal-libraries block, never checking a file on disk.

Proposed resolution

• Remove scripts/drupal-libraries-sync.js and scripts/assets/drupal-libraries.package.json.
• Rewire the Drupal CMS pre-test job in .gitlab-ci.yml: it no longer writes a package.json, no longer copies the script in, and no longer runs yarn at all.
• Require mnsami/composer-custom-directory-installer and wire the two installer paths a generic web/libraries/{$name} rule cannot place: web/libraries/swagger-ui for swagger-api/swagger-ui (which is type: library, not drupal-library), and the nested web/libraries/ckeditor5/plugins/media-embed that drupal/ckeditor_media_embed loads from.
• Assert the library files the .libraries.yml entries load are on disk, instead of counting entries in a package.json block — a count could pass while an installer path was wrong or an upstream layout had changed.

Verified on a freshly installed Varbase 11.4.5 site in DDEV with the packages resolved from Packagist and no VCS repositories: 14/14 declared library files present, 10/10 assets HTTP 200, 7/7 Drupal libraries discovered with every asset resolving, status report green, and yarn install succeeds with none of the six npm library packages present.

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

• N/A

API changes

• N/A

Data model changes

• N/A

Release notes snippet

• The Drupal CMS pre-test job now gets the front-end libraries from Composer installer paths instead of a yarn sync, and asserts the library files the components load are on disk.