Ship a package.json with the list of front-end dependencies, which will allow integrating with tools like Foxy

Problem

Webform's JavaScript dependencies are a lot of work, for both the maintainer and site owners.

The maintainer keeps track of each library's version in several places at once: WebformLibrariesManager, webform.libraries.yml, composer.libraries.json, and a zip archive in a sandbox module. Updating one library means touching all of them. The full ritual is documented in UPDATE-LIBRARIES.md.

Site owners get three options, none of them great:

• Copy composer.libraries.json into their root composer.json by hand. This adds ~270 lines of fake Composer package definitions, one per library.
• Download and extract a zip archive.
• Run Webform's custom Drush commands.

All of these are Webform-specific workflows that people have to learn.

Proposed solution

Ship a package.json in the Webform module that lists its JavaScript dependencies with normal npm versions.

That one file makes Webform's dependencies readable by standard JavaScript tooling. For example, sites that use Foxy (a Composer plugin that runs npm install for PHP packages that ship a package.json) would get all of Webform's libraries installed automatically during composer install. No hand-merging, no zip file, no extra Drush commands.

The package.json itself is tool-agnostic. Foxy is one consumer, but anything that reads npm manifests can use it. Webform wouldn't require any specific tooling. It would just declare its dependencies in the standard way.

Over time, this could let us delete:

• composer.libraries.json and the command that generates it
• The zip archive and its sandbox module
• Most of the webform:libraries:* Drush commands
• Most of the update ritual in UPDATE-LIBRARIES.md

Updating a library would mean changing one line in package.json.

What this issue does NOT cover

npm installs packages into node_modules, which usually lives outside the web root. Drupal expects libraries under /libraries, where the web server can reach them. So the installed assets would need to be copied or symlinked into the web root somehow, and Webform's library definitions would need to point at the new paths.

That problem is solvable, but it deserves its own discussion. This issue is only about declaring the dependencies in a standard format.

Prior art

Drupal CMS is exploring this approach on an experimental branch for its drupal_cms_forms recipe, which depends on Webform. The recipe has a package.json listing the libraries Webform needs. But Drupal CMS has not committed to this approach yet. Whether it moves forward depends partly on whether Webform itself is open to shipping its own package.json. If Webform did, the recipe could drop its duplicate list, and the approach would have a real foundation to build on.

This issue was drafted by an AI assistant under human supervision. @phenaproxima reviewed it before posting.