What about adding composer.json to PHP? like package.json in JavaScript


As some JavaScript exercises have package.json, why don’t we have composer.json for the PHP exercises too? This will equally make it easy for people to run unit tests locally too, without downloading the PHPUnit.phar or install PHPUnit with composer globally.

I could help create compose.json files for the exercises, when we agree on the naming convention etc.

Suggested composer.json could be.

    "name": "exercism-php/<exercise-name>",
    "description": "Short Exercise Description",
    "license": "same as exercism repos",
    "type": "project",
    "homepage": "link-to-exercise",
    "require": {
        "php": "^8.1"
    "require-dev": {
        "phpunit/phpunit": "^10.5"
    "minimum-stability": "dev",
    "prefer-stable": true,
    "scripts": {
        "test:unit": [
            "[ -e vendor/bin/phpunit ] || composer update",
            "vendor/bin/phpunit FileTest.php"

This would enable all to execute the tests locally, but running

composer install
composer test

Would be quite convenient.

What do you think about it?

Even I am very much in favour of composer in professional environments, here we would shift the problem from “downloading PHPUnit once” to “downloading composer once + executing additional commands per exercise + additional disk space usage per exercise”.

Also much of the information in each exercises composer.json needs to be maintained (at least kept in sync) when PHP versions change or names / descriptions are adjusted. There is tooling to take care of the tracks configuration files when upstream changes need to be applied to the track files, but composer.json would be unique to this track and not adjusted automatically.

And as a last point, composer.json could be used only by those using a CLI to learn. In the online environment an exercises composer.json is useless.

Just for clarification: This is my opinion and I’m no track maintainer.


I completely agree with you. But jest for JavaScript can be installed globally too, and you would not need the node_modules every time.

The reason why I’m suggestion it is that it’s done for JavaScript as well. So I thought, why not.

I have no problem having PHPUnit globally.

I don’t know who is the PHP track maintainer, perhaps that person will comment at some point.

(Admin note: Moved this to the php category. cc @neenjaw)

I can agree that composer is the de facto standard for package management in php applications, however as we have no libraries other than phpunit, we either ask people to install composer or ask people to download phpunit.

From a maintenance perspective, adding a composer.json for every single exercise adds a burden to maintain over time which I’m not keen to add to my plate at the moment.

I think this could make sense if there was an existing maintainer willing to do it or if our statistics showed that most exercises submitted were being submitted through the CLI rather than the web.

I understand, that I can mean more maintenance. A reason for not doing it. I can do it once, but it will need regular maintenance, which I cannot take on.

Then I think this can wait until we get a maintainer that is willing to take on this responsibility.

Thanks for the suggestion though

I think that’s a good solution. I might sign up for the “job” later. But cannot currently.

1 Like