Fix PHPStan L1 errors "Access to an undefined property Foo\Bar::$baz"

Should we consider adding DiffEngine to excludePaths?

Should we consider adding DiffEngine to excludePaths?

Pondered about that myself.
Decided against it, because it's not really "visual" for the average user that the file is excluded.
If only PHPStan had something like @phpstan-ignore-file...

Anyway, that's just my personal opinion, happy to be convinced to go the excludePaths route :)

Should we consider adding DiffEngine to excludePaths?

I would suggest no. In D11 the file will be gone, anyway. In the meantime, any refactoring introducing more errors will be at least pointed out. That applies to any deprecated file, imho.

Lots of places we can drop @var following #3238192: Allow omitting @var for strictly typed class properties →

Hello @longwave, noticed in #3238192: Allow omitting @var for strictly typed class properties → that we can omit @var only for strictly typed class properties.
If we look at the Proposed resolution → section, it says "This type can not be represented in the PHP typesystem yet." to variables like @var int|string|NULL

class Foo {
  /**
    * Where one can order a soda.
    */
  protected Bar $baz;

  /**
    * Some complex type that probably needs cleaning up in a future.
    * 
    * This type can not be represented in the PHP typesystem yet.
    *
    * @var int|string|NULL
    */
   public $someVar;
}

So can we really remove @var here:

• https://git.drupalcode.org/project/drupal/-/merge_requests/3775/diffs#59...
• https://git.drupalcode.org/project/drupal/-/merge_requests/3775/diffs#c6...
• And many more instances in this MR...

Anywhere that we do declare the types on the following lines, we can remove @var, for example:

  /**
   * The connection chroot.
   *
   * @var string|bool
   */
  private string|bool $chroot;

Not so sure about

protected Connection|false $connection;

as I think |false is only valid in PHP 8.2 and we need to support PHP 8.1.

Can we create a new MR for 11.x instead of changing the target branch in the existing MR?

Can we create a new MR for 11.x instead of changing the target branch in the existing MR?

Ah, wasn't aware you were working on this at the moment. Put MR back to 10.1.x.
Feel free to change whatever you need, I'll be leaving this one alone.

Thanks! 🙂 Was just thinking about working on #14 suggestions.

In MR !3775 (against 10.1.x), if the change is not as expected, we can just revert the latest commit.

Spokje → changed the visibility of the branch 3347502-fix-phpstan-l1 to hidden.

Spokje → changed the visibility of the branch 10.1.x to hidden.

Spokje → changed the visibility of the branch 11.x to hidden.

Spokje → closed merge request !3775

Spokje → changed the visibility of the branch 3347502-low-hanging-fruit to hidden.

Small comments on the MR.

Believe all feedback for this one has been addressed

Saving credit. Needs a rebase.

Rebased.

Committed/pushed to 11.x, thanks!

catch → closed merge request !6436

Automatically closed - issue fixed for 2 weeks with no activity.