Drupal Core News: New community initiative: Frontend bundler

Adapted from: https://www.sitback.com.au/insights/article/working-with-javascript-in-d...

As far as I understand it, community initiatives exist because enough people say they’re interested and start working towards the initiative’s goals.

So I thought I would try starting an initiative to solve a problem I see pop up fairly regularly:

Basically: why isn’t there a standard way to install javascript dependencies?

Some modules have tried asset-packagist, but there are myriad problems with that:

I had a whinge about it in #australia-nz: https://drupal.slack.com/archives/C45SW3FLM/p1712295645835869 and took up larowlan’s generous offer to try to get a new initiative this off the ground.

He introduced me to Théodore (@nod_) the frontend framework manager and we three had a short discussion around suitable directions to take. This initiative would not be happening without their help and guidance, thank you so much Lee and Théodore 🙇‍♂️

We explored the idea of using import-maps to let the browser handle module imports and agreed that the cascading downloads would be an unacceptable performance burden on non-admin pages.

The result of that meeting was the idea of trying out publishing Drupal modules on npm, or at least an npm-like repository, since @larowlan mentioned that GitLab can provide one. I got started and wrote some scripts for gathering package names and putting them in a central package.json to be downloaded by npm/yarn/whatever.

Then @larowlan pointed out https://github.com/php-forge/foxy which I had seen, but didn’t really understand the power of. What I didn’t understand was that you could define a package.json file inside a composer package, make a couple of tweaks to composer.json and without publishing any kind of npm package, foxy would find it and treat it like one.

Cue a couple of weeks of messing around with foxy, composer and vite, and I have created a working prototype for compiling multiple Drupal modules (including custom modules if desired) in a project, and routing the library system to the new entry points:


It requires a few things:

Any module that wants to opt in:

  • Adds php-forge/foxy to require or require-dev in composer.json.

  • Adds a module-name.foxy.yml file to represent the library state when using foxy.

Site builders:

  • Have one or more modules that use foxy in their project

  • Require and enable drupal/foxy

  • Add a provided vite.config.js to their project (could this be done by the foxy module?)

  • Set up a way to run vite build (or their own implementation):

    • post-install/update commands

    • pipeline?

    • manually?

This is where you come in

The prototype is just a starting point. I want us to come together to define a new way of working with JavaScript in Drupal that everyone can and will want to use, similar to how drupal-composer/drupal-project pioneered effective usage of composer and was eventually adopted by core. I intend to keep working on this but I want it to be driven by the community, hence the initiative.

Things you can do right now:

  • Spread the word, recruit more people to the initiative, especially if they maintain a module with JS dependencies.

  • Try out the prototype and give feedback - no change is too big to explore.

  • Join the #frontend-bundler-initiative channel to chat about ways forward - bikeshedding is welcome here, we used to call that brainstorming ;)

  • If you have a module with JS dependencies: speak up to have your module included in the prototype, or make a PR.

  • Contribute to the foxy module to get it to import css/image/asset dependencies from the vite manifest

So what do you say, are you in?- come join me in the channel!