Replace .info.yml with composer.json for extensions

Created on 9 January 2012, almost 13 years ago

Updated 3 November 2023, about 1 year ago

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"
    }
  }
}

✨ Feature request

Status

Postponed

Component

Idea

Created by

🇺🇸United States neclimdul Houston, TX

Live updates comments and jobs are added and updated live.