Now that we have an initiative to get get a composer.json file in each contrib module, we cal start getting them all on Packagist.
Back in April the Drupal community decided on a naming convention for projects on Drupal.org. Projects must use the package name
PROJECTis the part from the URL.
Using drupal as the vendor name in the package name allows us to lock down Packagist to a select list of maintainers. Currently this is the people who submitted a package to Packagist under the drupal vendor name before May 7th when the restriction was added.
The Packagist API currently allows us to update existing packages, so we could quite easily add a hook_node_update and hook_node_insert to drupal.org that will do this when project releases are updated or added. The API doesn’t offer a create endpoint, so we can’t automatically create new packages, an issue on Github has been opened for this, and I’ve started work on a pull request.
Once we have the Packagist pull request done, and the hooks added to drupal.org we can use the API key from Packagist for one of the maintainers (maybe Dries?) to push any new module or existing module updates across. Packagist will read directly from the drupal.org git repo and we’ll finally have one canonical place for all Drupal modules and PHP dependencies.
Drupal.org issue: https://www.drupal.org/node/2547617
Welcome to the wonderful world of Composer, the Dependency Manager for PHP! In this tutorial, you'll learn how to install and configure Composer and use it to integrate third-party libraries into any PHP project. We'll walk through:
- How Composer makes sharing awesome again
- Downloading the composer.phar file
- Creating the composer.json file
- Installing the external libraries
- Handling autoloading
- Understanding the composer.lock file
- The update versus install command
- The require command
- Storing in version control