Result Cache

PHPStan caches the result of the analysis so the subsequent runs are much faster. You should always analyse the whole project - the list of paths passed to the analyse command should be the same to take advantage of the result cache. If the list of paths differs from run to run, the cache is rebuilt from the ground up each time.

You might notice the result cache isn't sometimes saved and PHPStan runs full analysis even if nothing changed since the last run. If the analysis result contains some serious errors like parse errors, result cache cannot be used for the next run because the files dependency tree might be incomplete.

The result cache is saved at %tmpDir%/resultCache.php. Learn more about tmpDir configuration »

Result cache contents

• The last time a full analysis of the project was performed. The full analysis is performed at least every 7 days.
• Analysis variables used to invalidate a stale cache. If any of these values change, full analysis is performed again.
  • PHPStan version
  • PHP version
  • Loaded PHP extensions
  • Rule level
  • Configuration files hashes
  • Analysed paths
  • composer.lock files hashes
  • Stub files hashes
  • Bootstrap files hashes
  • Autoload file hash
  • Result cache meta extensions
• Errors in the last run
• Dependency tree of project files. If file A.php was modified since the last run, A.php and all the files calling or otherwise referencing all the symbols in A.php are analysed again.

Clearing the result cache

To clear the current state of the result cache, for example if you're developing custom extensions and the result cache is getting stale too often, you can run the clear-result-cache command. Learn more »

Result cache also gets disabled when running with --debug.

Debugging the result cache

If you run the analyse command with -vv, PHPStan will output details about the result cache like:

• "Result cache not used because the cache file does not exist."
• "Result cache not used because of debug mode."
• "Result cache was not saved because of internal errors."
• "Result cache is saved."
• etc.

Setup in Continuous Integration

Taking advantage of the result cache in your CI pipeline can make your build a lot faster.

Here's an example of cache setup in GitHub Actions. First, set tmpDir in your configuration file to be inside your workspace:

parameters:
	tmpDir: tmp

Setup in GitHub Actions

Because GitHub Actions do not overwrite existing cache entries with the same key, we need to make sure the cache always has a unique key. Also, we can save the cache even for failing builds with reported errors. Here's how the steps in a workflow could look like:

  # checkout, setup-php, composer install...
  
  - name: "Restore result cache"
    uses: actions/cache/restore@v4
    with:
      path: tmp # same as in phpstan.neon
      key: "phpstan-result-cache-{% raw %}${{ github.run_id }}"{% endraw %}
      restore-keys: |
        phpstan-result-cache-

  - name: "Run PHPStan"
    run: "vendor/bin/phpstan"

  - name: "Save result cache"
    uses: actions/cache/save@v4
    if: {% raw %}${{ !cancelled() }}{% endraw %}
    with:
      path: tmp # same as in phpstan.neon
      key: "phpstan-result-cache-{% raw %}${{ github.run_id }}"{% endraw %}

Learn more: Workflow syntax for GitHub Actions, actions/cache

Setup in GitLab CI

phpstan:
  cache:
	  key: "phpstan-result-cache-$CI_COMMIT_REF_NAME"
	  fallback_keys:
	    - "phpstan-result-cache-$CI_DEFAULT_BRANCH"
    paths:
      - tmp # same as in phpstan.neon
    when: 'always'

Learn more: Get started with GitLab CI/CD