Enhance your productivity on your PHP projects
Tags: php, codequality, gitlabci, refactoring
Published: 2020-03-06 09:15:49

---
title: Enhance your productivity on your PHP projects
published: true
date: 2019-10-28 00:00:00 UTC
tags: php, codequality, gitlabci, refactoring
canonical_url: https://www.dylan-ballandras.fr/blog/enhance-productivity-php/
---

For every new projects I have to work on, I always start by adding at least 3 libraries to ease my workflow.

- [PHPStan](https://github.com/phpstan/phpstan) - A static analysis tool
- [Psalm](https://psalm.dev/) - An advanced static analysis tool
- [Easy Coding Standard](https://github.com/SyliusLabs/CodingStandard) - Pack of rules for Simplify/EasyCodingStandard

They have become my best friends with PHPStorm in order to refactor every piece of code.

## [<svg viewbox="0 0 16 16" width="16" height="16" fill="currentcolor" aria-hidden="true"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg>](#why-do-you-need-static-analysis)Why do you need Static Analysis?

At first, if you are not familiar with static analysis tools, let me explain what they are.You write PHP interfaces, classes, methods and so on. All of that code is orcherstrated to make beautifull apps.But you should know that when adding new features, you may create potential bugs. Here is where those tools come in.

Static Analysis tools are programs that analyse other codebases without actually executing it. You could find a lot of thosetools online. For instance, there’s a [Wikipedia page](https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis) listing all known projects.

They will parse all of your code and try to find potential errors thanks to types and [AST](https://en.wikipedia.org/wiki/Abstract_syntax_tree).

> [Curated list of PHP Static Analysis tools](https://github.com/exakat/php-static-analysis-tools)

If you’re not convinced yet, here is another view on PHPStan:

[How to configure PHPStan for Symfony applications](https://blog.martinhujer.cz/how-to-configure-phpstan-for-symfony-applications/)

> Nowadays I can’t imagine developing modern PHP applications without PHPStan running on max level with lots of checks.It helps to prevent many issues during development and refactoring of the applications.

## [<svg viewbox="0 0 16 16" width="16" height="16" fill="currentcolor" aria-hidden="true"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg>](#why-do-you-need-a-code-style-library)Why do you need a Code Style library?

EasyCodingStandard describes itself as “Easiest way to start using PHP CS Fixer and PHP\_CodeSniffer with 0-knowledge”.Those two sub-packages enables your team to create a set of style rules to follow during the life of the project.

Even if you’re working alone, you can take advantage of such tool. Think about projects you left aside for a few month.

## [<svg viewbox="0 0 16 16" width="16" height="16" fill="currentcolor" aria-hidden="true"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg>](#now-how-to-automatically-use-it)Now, how to automatically use it?

You will only need those two commands to run:

- `vendor/bin/phpstan analyse src --level=max`
- `vendor/bin/ecs check src --fix`

### [<svg viewbox="0 0 16 16" width="16" height="16" fill="currentcolor" aria-hidden="true"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg>](#step-1-make-it-simple)Step 1: Make it simple

Write a `Makefile`:

```make
app@tests: app@lint-php app@quality-tests

app@lint-php:
	vendor/bin/ecs check src
	
app@lint-git-diff:
	vendor/bin/ecs check $$(git diff --name-only --diff-filter=ACMRTUXB HEAD~..HEAD -- '*.php')

app@lint-php-fix:
	vendor/bin/ecs check src tests --fix

app@quality-tests: app@php-analysis

app@php-analysis:
	vendor/bin/phpstan analyse src --level=max
	vendor/bin/psalm
```

You could also make it works with composer scripts and any other tool you’re familiar with.

Then use `make app@tests` to be able to spot error prone php code you wrote.Or make use of [GrumPHP](https://github.com/phpro/grumphp) to add pre-commit hooks if you want to enforce rules before each commit.You could also follow the next part about Gitlab-CI.

### [<svg viewbox="0 0 16 16" width="16" height="16" fill="currentcolor" aria-hidden="true"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg>](#step-2-every-push-should-be-follow-by-a-ci-validation)Step 2: Every push should be follow by a CI validation

But to be sure to really automate all the things, write a `.gitlab-ci.yml` file. It will be your best friend before merging Merge Requests. :D

```yaml
image:
  name: "your-super-duper-php-docker-image" # Or any Docker image
  entrypoint: [""]

before_script:
  - composer install --prefer-dist --no-progress --no-suggest --no-interaction

variables:
  CI_DEBUG_TRACE: "false"
  GIT_SSL_NO_VERIFY: "true"

tests:
  tags:
    - 'docker'
  script:
    - composer validate --no-check-publish
    - php bin/console security:check composer.lock --end-point=https://security.symfony.com/check_lock # If you're working on a Symfony project
    - vendor/bin/ecs check $(git diff --name-only --diff-filter=ACMRTUXB HEAD~..HEAD -- '*.php')
    - php vendor/bin/phpstan analyse src --level=max
```

If your CI Jobs are reds, you should block any merge from performing before a new validation.

I prefer to check code style only for the git diff for old projects with a lot of code smells. It also make it easier to review your merge requests as you won’t modify unrelated files.

I don’t enforce Psalm rules yet. I just started to work with it on newer projects. However, it has a greater understanding of PHPDoc, a [specific set of annotation](https://psalm.dev/docs/annotating_code/supported_annotations/), [templating](https://psalm.dev/docs/annotating_code/templated_annotations/), [assertions](https://psalm.dev/docs/annotating_code/adding_assertions/) and great [php projects refactoring tools](https://psalm.dev/docs/manipulating_code/refactoring/)

With this toolchain, you’re ready to work fast but with a nice seatbelt!Furthermore, you could add smoke tests with PHPUnit to your API/Website/CLI project to start with baby steps in the Unit Tests world. 💪

Honestly, I would love to know what are the equivalent most use tools for `C#`!