Problem/Motivation
Five years ago some of us bravely put forth adding metadata files to Drupal modules in
#80952: Add .info files to modules to store meta information →
. Today, tons of problems are trying to be solved by .info files in a Drupal specific way. It'd would hopefully lower a lot of core developer workload and provide a better solution if we could consider an external standard like composer.json
Proposed resolution
With Drupal 8's growing use of NIH solutions I thought I should propose another solution for this problem developed by the php community, the composer.json file. It has places for I believe all of the features requested to be added to .info files, appears to support all the fields we add as part of our packaging, has some nice features like PSR-0 that could help solve other problems we haven't encountered yet, and has a nice "extra" field we could stash our custom things like CSS files in themes, and best of all is not a Drupalism!
Key ideas:
Composer.json is a format outlined in this schema:
https://github.com/composer/composer/blob/master/res/composer-schema.json
Composer is also a PHP PSR-0 application for resolving dependencies generally used as a phar archive:
https://github.com/composer/composer
Packagist is a solr + symfony application serving http://packagist.org/ much like our project.module
https://github.com/composer/packagist
Pluses
- Its could mean engadgement of more people in the php community outside of d.o(adding drupal support for you code might be as easy as droping a line in your composer.json)
- NIH
- Composer is a very featureful package management system based on npm and suse
- Tests we don't have to maintain! http://travis-ci.org/#!/composer/composer
- Likely better drush support through things like the "repositories" entry and being able to reference libraries outside the drupal world for downloading.
- It would deprecate, or at least significantly improve the maintainability of project.module.
- A lot of people know json
Minuses
- The composer resolver does contain a lot of code
- Its JSON and CMI at this point has chosen to go with XML. Configuration is not definition though so this should be a minimal overhead. drupal.org could also probably automate a lot of the management if we're smart.
- JSON has no commenting like
<!-- -->, // or /* */.
- JSON is very strict?(maybe a good thing?)
Related Issues
Remaining tasks
Code review of composer.json
User interface changes
Not really a UI thing other then implementing new features we'll be able to support.
API changes
How a .info file would be translated to a composer.json file:
As you can see, most of it would be moved to the "extra" information of composer.json. One of the issues is the Drupal version being part of the packaged version information.
#1612910: [policy, no patch] Switch to Semantic Versioning for Drupal contrib extensions (modules, themes, etc) →
and
#586146: [policy, no patch] Decide if and how to implement semantic versioning for Drupal 8.x →
would help, but there are ways we can get around it in the mean time, as I outlined above. Here's an example of system.info as a composer.json file:
{
"name": "drupal/system",
"title": "System",
"type": "drupal-module",
"description": "Handles general site configuration for administrators.",
"extra": {
"drupal": {
"package": "Core",
"version": "VERSION",
"required": true,
"configure": "admin/config/system"
}
}
}