Download the PHP package rector/type-perfect without Composer
On this page you can find all versions of the php package rector/type-perfect. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package type-perfect
Type Perfect
Next level type declaration check PHPStan rules.
We use these sets to improve code quality of our clients' code beyond PHPStan features.
- These rules make skipped object types explicit, param types narrow and help you to fill more accurate object type hints.
- They're easy to enable, even if your code does not pass level 0
- They're effortless to resolve and make your code instantly more solid and reliable.
If you care about code quality and type safety, add these 10 rules to your CI.
Install
Note: Make sure you use phpstan/extension-installer to load the necessary service configs or include vendor/rector/type-perfect/config/extension.neon file.
There are 2 checks enabled out of the box. First one makes sure we don't miss a chance to use instanceof to make further code know about exact object type:
:no_good:
↓
:heavy_check_mark:
Second rule checks we use explicit object methods over magic array access:
:no_good:
↓
:heavy_check_mark:
Configure
Next rules you can enable by configuration. We take them from the simplest to more powerful, in the same order we apply them on legacy projects.
You can enable them all at once:
Or one by one:
1. Null over False
Bool types are typically used for on/off, yes/no responses. But sometimes, the false is misused as no-result response, where null would be more accurate:
:no_good:
↓
We should use null instead, as it enabled strict type declaration in form of ?Product since PHP 7.1:
:heavy_check_mark:
2. No mixed Property
This rule focuses on PHPStan blind spot while fetching a property. If we have a property with unknown type, PHPStan is not be able to analyse it. It silently ignores it.
It doesn't see there is a typo in vale property name. It should be value
:no_good:
↓
This rule makes sure all property fetches know their type they're called on.
:heavy_check_mark:
3. No mixed Caller
Same as above, only for method calls:
It doesn't see there is a typo in someMetho name, and that the 2nd parameter must be string.
:no_good:
↓
This group makes sure methods call know their type they're called on.
:heavy_check_mark:
4. Narrow Param Types
The more narrow param type we have, the reliable the code is. string beats mixed, int beats scalar and ExactObject beats stdClass.
In case of private, but also public method calls, our project often knows exact types that are passed in it:
But out of from fear and "just to be safe", we keep the addPrice() param type empty, mixed or in a docblock.
:no_good:
↓
If, in 100 % cases the float type is passed, PHPStan knows it can be added and improve further analysis:
That's where this group comes in. It checks all the passed types, and tells us know how to narrow the param type declaration.
:heavy_check_mark:
5. Narrow Return Types
Last but not least, the more narrow return type, the more reliable the code.
Where does it help? Let's say we have 2 types of talks, that do have different behavior:
Then we have a factory (repository, or services) that returns generic Talk type:
In this case we've just lost strict type and have to verify the type on runtime:
:no_good:
↓
That's where this group comes in. In case we return the exact type, we should use exact type in return type declaration to keep the code as reliable as possible:
:heavy_check_mark:
Add sets one by one, fix what you find helpful and ignore the rest.
Happy coding!
