Modernizing composer.json #

Part 4, chapter 12. Most extensions from before 2014 have no composer.json at all: they were downloaded as an archive and unpacked into extension/. Those from 2014 to 2020 usually have one, written for an older installer and an older PHP. This chapter brings either case up to date. The meaning of each field is explained in composer.json for an extension; here we go through what typically needs to change.

Case 1: no composer.json #

Create one in the extension's root. The smallest useful file:

{
    "name": "your-account/myoldext",
    "description": "My Old Extension: what it does, in one sentence.",
    "type": "ezpublish-legacy-extension",
    "license": "GPL-2.0-or-later",
    "require": {
        "php": "^8.0",
        "se7enxweb/ezpublish-legacy-installer": "*"
    },
    "extra": {
        "ezpublish-legacy-extension-name": "myoldext"
    }
}

• name: your GitHub account or organization and the repository name, lower case. If you upgrade someone else's extension in a fork, use your own account: a Packagist name belongs to whoever registered it.
• ezpublish-legacy-extension-name: the folder name the extension had. Keep it exactly, because settings, templates and other extensions refer to it.
• license: the SPDX identifier of the license the files already carry. The license is not yours to choose when you upgrade someone else's work.

Then validate it:

cd extension/myoldext
composer validate --no-check-publish

Case 2: an old composer.json #

These are the fields that are usually out of date, with what to change.

A real change: widening the PHP constraint #

From se7enxweb/expchangeclass, commit 32196f0, "installs and runs on PHP 8.0, the oldest PHP Exponential 6 supports":

before:
"php": "^8.1 || ^8.2 || ^8.3 || ^8.4"

after:
"php": "^8.0 || ^8.1 || ^8.2 || ^8.3 || ^8.4"

The commit message explains how that was justified: the code was checked with PHPCompatibility for PHP 8.0, linted and loaded with PHP 8.0.30, and served by PHP 8.0 on a full installation. Only then was the constraint widened. Never widen a constraint you have not tested.

Credit in composer.json #

When you upgrade or fork someone else's extension, they stay in authors. se7enxweb/expchangeclass lists the maintainer first and the original author of eZChangeclass second, with the role "Original author of eZChangeclass". The description says the same thing in words: "A hardened fork of eZChangeclass". More in Attribution and copyright notices.

Libraries the extension ships #

Old extensions often ship third-party libraries in a lib/ folder. When you add composer.json, you can move such a library into require instead, if it is on Packagist and its current version still does what the extension needs. Two cautions:

• An extension installed into extension/ by the legacy installer uses the site's vendor/ autoloader for its Composer dependencies. Test the extension in a site installed with Composer, not only in a copy.
• A library that went through several major versions since the extension was written may have changed its API. Read its changelog first.

If you keep the library in the extension, keep its license file next to it, and name it in ezinfo.php with an Includes entry (Modernizing ezinfo.php and extension.xml).

Check it #

composer validate --no-check-publish

Then install the extension from your repository into a test site, before you publish it on Packagist. The steps are in composer.json for an extension, section "Installing it from a repository before Packagist".

Related pages #

• Previous: Modernizing ezinfo.php and extension.xml
• Next: CSP: moving inline scripts into files
• Composer and Packagist
• The composer.json schema on getcomposer.org
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.