PHP Dev Tools (for CodinGame or elsewhere)

Using a dependency manager (Composer)

There are many more dev tools beyond the scope of this short intro playground. Some of them are not very useful in the context of CodinGame puzzles, but still very important to know them for real projects. In this playground I briefly mention some of them, but without much details.

Why?

While it is a nice achievement to build something from scratch, software development does not really work that way. There are tons of useful, high quality, open source packages you can build on in your project. However, these packages are also evolving, new versions appearing all the time. Also, a package you use might use another packages, so you will need also those. Multiple packages might rely on the same package, maybe with different version constraints. managing all of this can become quite complex pretty fast.

A dependency manager is a tool that handles all this stuff for you. In the PHP world, Composer became the de-facto standard dependency manager tool.

In case of Codingame puzzles, we cannot use any external packages, so Composer is of limited use.

Installing and basic usage

A full Composer tutorial is beyond the scope of this playground, so I will be very brief.

• Download and install it from its website, following the instructions.
• To use it in a project, you need a composer.json file. This file will contain the description of all your project dependencies (including allowed version number ranges), and some other settings.
  • You can create it manually with any text editor (including VS Code of course);
  • ... or you can run composer init, which asks some questions on the console, and then creates the file for you based on your answers.
• The composer install command will download and install all your stated dependencies in the vendor subdirectory.
  • This will also create a composer.lock file that locks the dependencies of your project to a known state.
• You can add third-party packages as dependencies with composer require vendorname/packagename.
  • Add --dev argument to specify that the package is required only in a development environment, but not in production (typical for a dev tool).
  • Packagist is the main Composer repository for all the packages available.
• Later you can upgrade all the packages you are using in your project with composer update.
• When dealing with version numbers, an important (yet simple) concept you need to be familiar with is Semantic Versioning.

While we don't use any packages for Codingame puzzles, we can still specify what php version and what core php libraries (extensions) our code needs.

So a possible, very simple composer.json file:

{
    "name": "your-github-profile-name/reponame",
    "description": "codingame puzzle solutions",
    "type": "project",
    "require": {
        "php": "^7.3|^8.0",
        "ext-bcmath": "*",
        "ext-ctype": "*",
        "ext-mbstring": "*"
    }
}

You can check if all your stated requirements are met on your local machine with:

composer check-platform-reqs

Creating custom scripts

A convenience feature of Composer is the ability to create custom commands or scripts. In the previous chapters we have used several tools from the command line, but needed to start them with several arguments (or to create additional batch files). We could use composer scripts as an alternative.

For example, the following fields can be added to the basic composer.json file above:

    "scripts": {
        "cs" :      "phpcs",
        "cs-fixer": "php-cs-fixer fix --dry-run --show-progress=dots --ansi --diff -vv",
        "stan":     "phpstan --ansi --verbose",
        "qa" : [
            "@cs",
            "@cs-fixer",
            "@stan"
        ],
        "clean" : [
            "if exist .tools\\.phpcs.cache          del .tools\\.phpcs.cache",
            "if exist .tools\\.php-cs-fixer.cache   del .tools\\.php-cs-fixer.cache",
            "if exist .tools\\phpstan\\             rmdir /S /Q .tools\\phpstan"
        ]
    },
    "scripts-descriptions": {
        "cs":       "Check coding style compliance to PSR12 with phpcs",
        "cs-fixer": "Check coding style compliance to PSR12 plus extra rules with php-cs-fixer (no fix applied)",
        "stan":     "Run static analysis with phpstan",
        "qa":       "Run code quality checks: phpcs, php-cs-fixer and phpstan",
        "clean":    "Delete dev tools cache (Windows only)"
    }

Here we defined several shortcuts. Now we can simply run the PHP CS Fixer tool with those predefined arguments with

composer cs-fixer

...or similarly, run PHPStan with composer stan.

The custom composer qa command runs multiple tools after each other. I use it as a 'catch-all' quality assurance command before I commit my changes to my repository at the end of a coding session. It could have been further automated with some CI/CD tools such as GitHub Actions, but it is more than enough for me for the CG puzzles.

Note: the above scripts still assume that the tools' config files are in the main project directory, as we discussed it in earlier chapters. Otherwise you would need more command line arguments.

The scripts-descriptions part is fully optional, these descriptions are used only by the composer list and composer help commands.

Useful links

• Composer
• Packagist

Coming next

Unit testing