For anyone not familiar with PHP, static analysis is pretty much required because the official PHP type system is minimal. The detailed types are added through phpdoc comments, and they also help IDEs to provide a sane completion. For instance, the plain "array" should be detailed with phpdoc:

    /**
     * @param array<string, MyRecord> $input
     * @return list<int>
     */
    function foo(array $input): array
    {
        foreach ($input as $string => $record) {
            // IDE knows $record is an instance of MyRecord

The static analysis will use both type systems, and it's the only way to check that phpdoc are consistent. Psalm has various levels of strictness, and even at a very lax level, it can help detect errors or code smells.

There are two major static analysis tools for PHP, Psalm and PHPstan, both written in PHP. The latter used to be much slower, but last time I tried it there was little difference (about 20 s for 100k lines + dependencies).

My guess is that a new contender, Mago, written in Rust, will probably soon replace those other tools. Its commands (analyze, lint) are already almost as complete as psalm/phpstan. Though the migration won't be easy because it does not have a notion of levels.

▲ bel8 4 hours ago | parent [-]

PHP type system is lacking but I wouldn't call it minimal.

PHP even has union types, just like TypeScript.

The major issue is the lack of array types and it's 90% of the reason I see projects using extra linting tools.

[1] https://php.watch/versions/8.0/union-types

▲ idoubtit 16 minutes ago | parent | next [-]

Maybe "minimal" was not the right word. I hope the context made clear that I meant the type system was lacking even for basic uses. Here are 3 common cases.

Some PHP functions (e.g. opening a file) return a `resource` type, but PHP has no official way to declare it. So the right way is to declare `mixed` as an official type (which means `any`) and fix that declaration with a phpdoc comment.

Phpdoc provides generics (named "templates", à la C++), e.g. `iterable<Something>` where `iterable` is an official PHP type (which is awfully imprecise without phpdoc).

Phpdoc has tuples and (associative) array shapes, e.g. `@return list{int, \Error}`.

In past PHP versions, the type system was worse because the internal types were ambiguous: types were implicitly nullable, i.e. `string` meant `null|string`. When PHP gradually added sum types, they fixed that ambiguity.

	▲	someothherguyy 6 minutes ago \| parent [-]
		> Phpdoc has tuples and (associative) array shapes, e.g. `@return list{int, \Error}`. `list<Error>` a `list<T>` is `array<int<0, max>, T>` (some differences in phpstan vs psalm vs mago)

▲ someothherguyy 17 minutes ago | parent | prev | next [-]

it has union and intersection types, but it is nothing like typescript.

▲ Timon3 3 hours ago | parent | prev | next [-]

> PHP type system is lacking but I wouldn't call it minimal.

PHP still doesn't have generics, right? IMO any type system without higher-order types is definitely on the minimal side.

▲ eithed 2 hours ago | parent [-]

Natively: no. Via tools like phpstan and psalm: yes, per OP. Link to relevant docs: https://psalm.dev/docs/annotating_code/templated_annotations... or https://phpstan.org/blog/generics-by-examples

One can declare:

  final class Door {}

  /**
   * @template T
   */
  final class Box
  {
      /** @param T $value */
      public function __construct(private mixed $value) {}

      /** @return T */
      public function get(): mixed
      {
          return $this->value;
      }
  }

  final class DoorInspector
  {
      /** @param Box<Door> $box */
      public function __construct(private Box $box) {}

      public function inspect(): void
      {
          $this->box->get()->open(); // analyser knows this is a Door
      }
  }

  new DoorInspector(new Box(new Door()));   // OK
  new DoorInspector(new Box('not a door')); // error: Box<string> given

You can even bind a template by a generic type with "of":

  final class Door {}

  /**
   * @template T
   */
  class Box
  {
      /** @param T $value */
      public function __construct(private mixed $value) {}

      /** @return T */
      public function get(): mixed
      {
          return $this->value;
      }
  }

  /** @extends Box<Door> */
  final class DoorBox extends Box {}

  /**
   * @template T
   * @template F of Box<T>
   */
  final class Shelf
  {
      /** @param F $box */
      public function __construct(private Box $box) {}

      /** @return F */
      public function box(): Box
      {
          return $this->box;
      }

      /** @return T */
      public function item(): mixed
      {
          return $this->box->get();
      }
  }

  $shelf = new Shelf(new DoorBox(new Door()));
  $shelf->box();  // DoorBox
  $shelf->item(); // Door

▲ wesammikhail 4 hours ago | parent | prev [-]

That's exactly it but PHP Core refuses to address the typed array issue in wait for a consensus on Generics even though those two things serve different audiences.

I haven't actually run into a single issue with PHP's type system in the last few years. Literally the only thing that remains is typed arrays but that seems to be ways off due to fragmentation in how the core devs want it handled.

	▲	hparadiz 4 hours ago \| parent [-]
		With how good PHPDoc and Phan are these days I don't really think about it anymore. You can sort of have typed array by implementing Iterator, Countable, ArrayAccess, and optionally Indexing but I assume you mean defining types of array values.