Skip to content

0.17.0

Choose a tag to compare

@dereuromark dereuromark released this 01 Nov 19:04
· 204 commits to master since this release

Improvements

Generics syntax instead of legacy array syntax

The old string[] syntax is deprecated and replaced by generics, as it can now also focus on key instead of just value:

  • array<string> (list) vs array<string, string> (associative array)
  • It is recommended not to upgrade collection objects outside of \ArrayObject and \ArrayAccess etc, as IDEs do not yet understand those. Here we can keep \MyCollection|\MyObject[] as legacy typehint in place. Custom @phpstan-* tags on top can be "clean" already.
  • You can check your code for all generics where keys can and should now be added (associative arrays usually are string-keyed).

The current ruleset auto-fixes this as follows:

  • Fixes nested string[][][] etc to array<array<array<string>>> as deep as necessary for all simple generics
  • \ArrayObject|type[] to \ArrayObject<type> (simple) generic objects understood by IDEs like PHPStorm
  • Keeps \Complex\Collection|type[] collection object - the only way to be understood by PHPStorm and still understood by PHPStan/Psalm
  • Disallows \Complex\Collection<type> as this is not yet understood by IDEs like PHPStorm
  • Disallows \Complex\Collection|array<type> as this is invalid as per PHPStan/Psalm
  • Valid is however \Redirect|array<keytype, valuetype> as long as the key is defined here as well, as this does not then count as generic collection object (iterating over values), but as two completely different types.

All files should be annotated using generics pattern to clarify iterable value type, and in case it cannot be clarified more would just be type<mixed>.
Where possible (speficially associative array), also always define (string) key type.

In some cases, extra PHPStan annotations on top might be necessary. But in most cases, those are not and should not be added.

Whenever you work with generic collection objects, it is advised to specify the "fully correct" syntax in phpstan-* tags on top. If known/possible, you can even specify the key here.

 * @phpstan-param \My\Collection<string, \Some\Ţransfer>
 * @param \My\Collection|\Some\Ţransfer[]

It is recommended now to remove the following part from your phpstan.neon files:

checkMissingIterableValueType: false

And if defined correctly, also this can be removed:

checkGenericClassInNonGenericObjectType: false

PHP 7.3+

With PHP 7.3 being already EOL soon, it only makes sense to drop the already very long EOL 7.2 version.
It is already PHP 8.1 tested, however, as well.

More quality sniffs

Quite a few more sniffs to make sure the code is also semantically checked even before any static analyzer like PHPStan/Psalm look at it.
Specifically interesting:

  • Spryker.Arrays.DisallowImplicitArrayCreation to avoid bugs and side effects
  • Spryker.Commenting.TypeHint to harmonize doc block type hints, ordered as well as unique
  • SlevomatCodingStandard.ControlStructures.RequireShortTernaryOperator to remove redundancy
  • SlevomatCodingStandard.ControlStructures.RequireNullCoalesceOperator to remove redundancy

Also:

  • Whitespace sniffs for a cleaner diff/patch creation, which will help upgradability moving forward (PHP 7.3+ sniffs).

It does by default disallow some newer PHP 8 language elements for the project to be 7.4+.
If you are running already PHP 8, you can exclude those using

<rule ref="vendor/spryker/code-sniffer/Spryker/ruleset.xml">
    <exclude name="SlevomatCodingStandard.Functions.DisallowNamedArguments"/>
    <exclude name="SlevomatCodingStandard.Functions.DisallowTrailingCommaInDeclaration"/>
    <exclude name="SlevomatCodingStandard.Classes.DisallowConstructorPropertyPromotion"/>
    <exclude name="SlevomatCodingStandard.ControlStructures.DisallowNullSafeObjectOperator"/>
    ...
</rule>