Migrate static code analysis from Psalm to PHPStan

[Meldiron]

Introduction

Static code analysis allows programmers to check their code for bugs ahead of time. There are many ways to do it, but this one specifically understands code without running it, allowing for very fast and reliable checks.

Starting this issue requires an understanding of PHP syntax. Finishing this issue will give you basic understanding about Composer (PHP package manager) and GitHub Actions.

Task summary

Your goal is to implement static code analysis in the following repositories:

• utopia-php/image
• utopia-php/orchestration
• utopia-php/registry
• utopia-php/config

1. Remove Psalm code analysis

Remove Psalm from all necessary places in the repository. Make sure those include:

• Removing from dependency manager (and it's lockfile)
• Removing Psalm configuration file
• Removing GitHub action automating Psalm code check

2. Install and configure PHPStan

Install PHPStan by using Composer, a PHP dependency manager.

Make sure the version for this dependency is set to automatically upgrade minor and patch versions, but not the major version.
If those terms seem new to you, check out Semantic Versioning.

To configure PHPStan, you use a specific JSON file. Please refer to the PHPStan documentation to learn more.
Your goal is to configure PHPStan in all repositories to the same settings. Please set it to the same settings as we used in another one of our open-source repositories open-runtimes/executor.

In rare scenarios, PHPStan can have issues seeing typings for PHP extensions such as Swoole or Redis. If this happens to you, you might need to mention their helpers in the scanDirectories of the PHPStan configuration.

3. Add command to run static code analysis

Set up Composer scripts called check. This command should run PHPStan on all directories including PHP files. We usually only store PHP code in directories src, app and tests, but make sure to double check it.

When running the PHPStan check, we strive for level 8 of strictness. We recommend you to start with low level of 1, and work your way up, inspecting new errors with each higher level.

If you face issue you can't find a way to solve, please discuss with us and in rare scenarios we allow ignoring a line of code in code analysis.

If you ever get stuck, you can again refer to open-runtimes/executor, to see how it's been done there.

4. Add GitHub automation

Add GitHub action to run linter (composer check) on each push, so pull requests run linter as check.

Store the new GitHub action in the code-analysis.yml file.

Just like before, if you feel stuck, you can refer to Open Runtimes Executor to validate your approach.