{"id":25209859,"url":"https://github.com/backdrop-contrib/composer_manager","last_synced_at":"2026-02-07T03:00:26.703Z","repository":{"id":235831805,"uuid":"790900419","full_name":"backdrop-contrib/composer_manager","owner":"backdrop-contrib","description":"Composer Manager allows Backdrop contributed modules to provide an option to use Composer to manage dependencies for PHP libraries.","archived":false,"fork":false,"pushed_at":"2026-01-16T22:44:49.000Z","size":134,"stargazers_count":1,"open_issues_count":3,"forks_count":3,"subscribers_count":7,"default_branch":"1.x-2.x","last_synced_at":"2026-01-18T05:12:40.188Z","etag":null,"topics":["backdrop","backdropcms","composer","dependencies","dependency","libraries","library"],"latest_commit_sha":null,"homepage":"https://backdropcms.org/project/composer_manager","language":"PHP","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"gpl-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/backdrop-contrib.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE.txt","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2024-04-23T18:24:30.000Z","updated_at":"2026-01-16T22:42:24.000Z","dependencies_parsed_at":null,"dependency_job_id":"36ae4447-84d0-4d02-a16f-c520d4d6ba26","html_url":"https://github.com/backdrop-contrib/composer_manager","commit_stats":null,"previous_names":["backdrop-contrib/composer_manager"],"tags_count":4,"template":false,"template_full_name":null,"purl":"pkg:github/backdrop-contrib/composer_manager","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/backdrop-contrib%2Fcomposer_manager","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/backdrop-contrib%2Fcomposer_manager/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/backdrop-contrib%2Fcomposer_manager/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/backdrop-contrib%2Fcomposer_manager/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/backdrop-contrib","download_url":"https://codeload.github.com/backdrop-contrib/composer_manager/tar.gz/refs/heads/1.x-2.x","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/backdrop-contrib%2Fcomposer_manager/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":29185107,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-02-07T00:44:15.062Z","status":"online","status_checked_at":"2026-02-07T02:00:07.217Z","response_time":63,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["backdrop","backdropcms","composer","dependencies","dependency","libraries","library"],"created_at":"2025-02-10T13:18:45.614Z","updated_at":"2026-02-07T03:00:26.655Z","avatar_url":"https://github.com/backdrop-contrib.png","language":"PHP","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Composer Manager\n\n[Composer Manager](https://backdropcms.org/project/composer_manager) provides a\ngateway to the larger PHP community by enabling Backdrop modules to more easily\nuse best-in-breed libraries that are managed by\n[Composer](https://getcomposer.org/).\n\nThere are [many challenges](#why-cant-you-just--) when using Composer with\nBackdrop, so the primary goal of this module is to work around them by wrapping\nComposer with common Backdrop workflows so that module developers and site\nbuilders can use the [thousands of standards-compliant, platform agnostic PHP\nlibraries](https://packagist.org/statistics) with as little friction as\npossible.\n\n## Installation\n\n* Install this module using the [official Backdrop CMS instructions](https://backdropcms.org/guide/modules)\n* Refer to the [Maintaining Dependencies](#maintaining-dependencies)\n  section for installing and updating third-party libraries required by\n  contributed modules\n* Refer to the [Best Practices](#best-practices) section for recommended module\n  configurations according to your environment\n\n## Usage For Site Builders\n\n### Maintaining Dependencies\n\nAs modules are enabled and disabled, Composer Manager gathers their requirements\nand generates a consolidated `composer.json` file in the \"Composer File\nDirectory\" as configured in Composer Manager's settings page. There are two ways\nto install and update the contributed modules' dependencies:\n\n#### Automatically With Drush (Recommended)\n\nUsing `drush en` and `drush dis` to enable and disable modules respectively will\nautomatically generate the consolidated `composer.json` file and run the\nappropriate Composer commands to install and update the required dependencies.\n\nThis technique introduces the least amount of friction with existing workflows\nand is strongly recommended.\n\nThe following Drush commands are also available:\n\n* `drush composer-json-rebuild`: Force a rebuild of the consolidated\n  `composer.json` file\n* `drush composer-manager [COMMAND] [OPTIONS]`: Pass through commands to\n  Composer, refer to the [cli tool's documentation](https://getcomposer.org/doc/03-cli.md)\n  for available commands and options.\n\n#### Manually With Composer\n\nIf you do not wish to use Drush, you must manually use Composer's command line\ntool to install and update dependencies whenever modules are enabled or\ndisabled. The following steps illustrate the workflow to maintain the\ndependencies required by contributed module:\n\n* Visit `admin/modules` and enable / disable the modules that have dependencies\n* Change into the the \"Composer File Directory\" as configured in Composer\n  Manager's settings page which is where the consolidated `composer.json` file\n  was generated\n* If necessary, [download and install](https://github.com/composer/composer/blob/master/doc/01-basic-usage.md#installation)\n  the Composer tool\n* Run `php composer.phar install --no-dev` on the command line, replace\n  `install` with `update` when updating dependencies\n\nRefer to [Composer's documentaton](https://getcomposer.org/doc/) for more\ndetails on how Composer works.\n\n### Configuring Composer Manager\n\nVisit `admin/config/system/composer-manager/settings` as a user with the\n`administer site configuration` permission to configure Composer Manager.\n\n### Best Practices\n\nUnfortunately there is arguably no 80% use case that guides sane defaults. Site\nbuilders will likely have to configure Composer Manager according to their\nenvironment, so this section outlines best practices and techniques to help\nguide a sustainable, reliable installation.\n\n#### Recommended Settings\n\nIt is recommended to maintain a project structure where the composer files and\n`vendor/` directory exist alongside the document root. This can be achieved by\nmodifying the following options in Composer Manager's settings page.\n\n* Vendor Directory: `../vendor`\n* Composer File Directory: `../`\n\nYou can also set the options in settings.php by adding the following variables:\n\n```php\n$config['composer_manager.settings']['vendor_dir'] = '../vendor';\n$config['composer_manager.settings']['file_dir'] = '../';\n```\n\n*NOTE:* The recommended settings are not the defaults because we cannot assume\nthat this structure is viable for all use cases. Furthermore, the \"Composer File\nDirectory\" is set to a path we know is writable by the web server so the\nautomatic building of `composer.json` works out of the box.\n\n#### Multisite\n\nIt is recommended that each multisite installation has its own library space\nsince the dependencies are tied to which modules are enabled or disabled and\ncan differ between sites. Add the following snippet to `settings.php` to group\nthe libraries by site in a directory outside of the document root:\n\n```php\n// Capture the site dir, e.g. \"default\", \"example.localhost\", etc.\n$site_dir = basename(__DIR__);\n$config['composer_manager.settings']['vendor_dir'] = '../lib/' . $site_dir . '/vendor';\n$config['composer_manager.settings']['file_dir'] = '../lib/' . $site_dir;\n```\n\n*NOTE:* The `sites/*/` directories may seem like an obvious location for the\nlibraries, however Backdrop removes write permissions to these directories on\nevery page load which can cause frustration.\n\n#### Production Environments\n\nDependencies should be managed in development environments and not in production.\nTherefore it is recommended to disable the checkboxes that automatically build\nthe composer.json file and run Composer commands when enabling or disabling\nmodules on production environments.\n\nAssuming that you can detect whether the site is in production mode via an\nenvironment variable, adding the following snippet to `settings.php` will\ndisable the options where appropriate:\n\n```php\n// Modify the logic according to your environment.\nif (getenv('APP_ENV') == 'prod') {\n  $config['composer_manager.settings']['autobuild_file'] = 0;\n  $config['composer_manager.settings']['autobuild_packages'] = 0;\n}\n```\n\n## Usage For Module Maintainers\n\nModule maintainers can use Composer Manager to maintain their dependencies by\ncreating a `composer.json` file in the module's root directory and adding the\nappropriate requirements. Refer to [Composer's documentation](https://getcomposer.org/doc/01-basic-usage.md#composer-json-project-setup)\nfor details on adding requirements.\n\nIt is recommended to use [version ranges](https://getcomposer.org/doc/01-basic-usage.md#package-versions)\nand [tilde operators](https://getcomposer.org/doc/01-basic-usage.md#next-significant-release-tilde-operator-)\nwherever possible to mitigate dependency conflicts.\n\nYou can also implement `hook_composer_json_alter(\u0026$json)` to modify the data\nused to build the consolidated `composer.json` file before it is written.\n\n### Maintaining A Soft Dependency On Composer Manager\n\n@todo\n\n### Accessing The ClassLoader Object\n\nOnce the autoloader is registered, you can retrieve the ClassLoader object by\ncalling `\\ComposerAutoloaderInitComposerManager::getLoader()`. The following\nexample uses this technique with Doctrine's Annotations library which requires\naccess to the loader object.\n\n```php\n\nuse Doctrine\\Common\\Annotations\\AnnotationRegistry;\n\n$loader = \\ComposerAutoloaderInitComposerManager::getLoader();\nAnnotationRegistry::registerLoader(array($loader, 'loadClass'));\n\n```\n\n### Relying on composer manager in .install\n\nComposer manager will automatically handle the autoloader in `hook_init()`, so\nmodules generally don't have to worry about triggering the autoloader. However\nthere are occasions where `hook_init()` isn't invoked such as during install and\nupdate.php. If you rely on the autoloader in a .install file, you have to make\nsure the autoloader is triggered by running\n`composer_manager_register_autoloader()` at the beginning of your update\nfunction or your `hook_install()` implementation.\n\n## Why can't you just ... ?\n\nThe problems that Composer Manager solves tend to be more complex than they\nfirst appear. This section addresses some of the common questions that are asked\nas to why Composer Manager works the way it does.\n\n### Why can't you just run \"composer install\" in each module's root directory?\n\nIf a module contains a `composer.json` file, running `composer install` in its\nroot directory will download all requirements and dependencies to `vendor/`\ndirectories with their own autoloaders. Relying on this technique poses multiple\nchallenges:\n\n* Duplicate library code when modules have the same dependencies\n* Unexpected classes being sourced depending on which autoloader is registered\n  first\n* Potential version conflicts that aren't detected since each installation is\n  run in isolation\n\nTo highlight the challenges, let's say `module_a` requires\n`\"guzzle/http\": \"3.7.*\"` and `module_b` requires `\"guzzle/service\": \"\u003e=3.7.0\"`.\nAt the time of this post, running `composer install` in each module's directory\nwill result in version 3.7.4 of `guzzle/http` being installed in `module_a`'s\n`vendor/` directory and version 3.8.1 of `guzzle/service` being installed in\n`module_b`'s `vendor/` directory.\n\nBecause `guzzle/service` depends on `guzzle/http`, you now have duplicate\ninstalls of `guzzle/http`. Furthermore, each installation uses different\nversions of the `guzzle/http` component (3.7.4 for `module_a` and 3.8.1 for\n`module_b`). If `module_a`'s autoloader is registered first then you have a\nsituation where version 3.8.1 of `\\Guzzle\\Service\\Client` extends version 3.7.4\nof `\\Guzzle\\Http\\Client`.\n\n#### Composer Manager's Solution\n\nComposer Manager finds all `composer.json` files in each enabled module's root\ndirectory and attempts to gracefully merge them into a consolidated\n`composer.json` file. This results in a single vendor directory shared across\nall modules which prevents code duplication and version mismatches. For the use\ncase above, Composer will resolve both `guzzle/http` and `guzzle/service` to\nversion 3.7.4 which is a more consistent, reliable environment.\n\n#### Challenges With Composer Manager\n\nThe challenge of Composer Manager's technique is when multiple modules require\ndifferent version of the same package, e.g. `\"guzzle/http\": \"3.7.*\"` and\n`\"guzzle/http\": \"3.8.*\"`. Composer Manager will use the version defined in the\n`composer.json` file that is associated with the module with the heaviest weight.\nComposer Manager will also flag the potential version conflict in the UI so the\nsite builder is aware of the inconsistency.\n\n### Why can't you just manually maintain a composer.json file?\n\nManually maintaining a `composer.json` file provides a single library space that\nall modules can share, however relying on this technique poses multiple\nchallenges:\n\n* Site builder responsible for updating file when modules are enabled or updated\n* Dependencies are decoupled from the module's codebase\n* Multiple files must be maintained for each multisite installation\n\n#### Composer Manager's Solution\n\nComposer Manager automatically generates the `composer.json` file when modules\nare enabled and disabled, and there is an option in the UI with a corresponding\nDrush command that can rebuild the consolidated `composer.json` file on demand.\nFurthermore, using a Drush based workflow will automatically run the appropriate\ncomposer commands whenever modules are enabled or disabled, so the need to run\nComposer commands outside of normal workflows is reduced to module updates.\n\n#### Challenges With Composer Manager\n\nThere are multiple challenges posed by Composer Manager's technique:\n\n* Web server needs write access to the composer file directory\n* Sane multisite configuration requires environment-specific `settings.php`\n  configurations\n* Must implement `hook_composer_json_alter()` in a module to modify\n  `composer.json`\n\n#### Composer Manager's Solution\n\nRefer to the [Why can't you just manually maintain a composer.json file?](#composer-managers-solution-1)\nsection.\n\n#### Challenges With Composer Manager\n\nRefer to the [Why can't you just manually maintain a composer.json file?](#challenges-with-composer-manager-1)\nsection.\n\n## Current Maintainers\n\n - [Laryn Kragt Bakker](https://github.com/laryn).\n - Collaboration and co-maintainers welcome!\n\n## Credits\n\n - Ported to Backdrop CMS by [Laryn Kragt Bakker](https://github.com/laryn).\n - Support has been provided by [Aten Design Group](https://aten.io).\n - Maintained for Drupal by [Bojan Živanović](https://www.drupal.org/u/bojanz),\n   [Chris Pliakas](https://www.drupal.org/u/cpliakas),\n   [Andrew Berry](https://www.drupal.org/u/deviantintegral),\n   [Nathaniel Hoag](https://www.drupal.org/u/n8nl), and\n   [Richard Burford](https://www.drupal.org/u/psynaptic).\n\n ## License\n\nThis project is GPL v2 software. See the LICENSE.txt file in this directory for\ncomplete text.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fbackdrop-contrib%2Fcomposer_manager","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fbackdrop-contrib%2Fcomposer_manager","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fbackdrop-contrib%2Fcomposer_manager/lists"}