They are quite useful and reduce typing time.
https://phpstan.org/writing-php-code/phpdoc-types#local-type-aliases
https://psalm.dev/docs/annotating_code/supported_annotations/#psalm-type
They are quite useful and reduce typing time.
https://phpstan.org/writing-php-code/phpdoc-types#local-type-aliases
https://psalm.dev/docs/annotating_code/supported_annotations/#psalm-type
ging-dev Thank you for the tip. Good idea!
@ging-dev Agreed! I added a note in https://community.devsense.com/d/614-support-for-phpstan/29 before I saw this post.
We have implemented local type aliases (@phpstan-type
and @psalm-type
), available in the latest pre-release.
Thank you for your feedback!
Amazing, @JakubMisek! I purchased a license after hearing this and hope to do so for more of our team soon.
Do you think there's ever a possibility of supporting global type aliases from PHPStan?
claygriffiths Hi Clay, and thank you for your purchase!
Definitely, we'll be implementing local type alias import (@phpstan-import-type
) first, and then global aliases.
claygriffiths quick question - is your phpstan.neon
, phpstan.neon.dist
or phpstan.dist.neon
in the workspace root? Or you have a custom file name or using a nested directory for it? )
JakubMisek Since we're working with WordPress plugins, we keep our linting configs (ESLint, PHPCS, PHPStan, etc.) in the root of each plugin we maintain.
While phpstan.dist.neon
/ phpstan.neon.dist
is the recommended file to check into VCS, we currently use phpstan.neon
as the file as we haven't had a need for overriding a dist file.
To recap, we have our workspace root in VS Code as the webroot of a WordPress site which contains folders such as index.php
, wp-content
, wp-includes
, etc.
Then, in wp-content/plugins
, we have our plugins each containing their own configs.
Ideally whichever file you have open, it would try to find the closest phpstan.neon
file, but this hasn't really been a pattern I've seen in VS Code outside of maybe ES Lint. For PHP_CodeSniffer, we just use a fairly loose config in the workspace root and let CI/CD catch more specific errors.
If that's the direction you have to go with the PHPStan config, I can understand. We'd still get a ton of value out of being able to plop a config in the workspace root containing a bunch of type aliases.
claygriffiths Thank you very much for the details, that makes sense!
claygriffiths global type aliases will be available in the next pre-release.
It will also implement @phpstan-import-type
, which is used a lot i.e. in Symfony.
JakubMisek Are there docs on how to use global type aliases with DevSense for VS Code?
I've put a phpstan.neon
(tried phpstan.dist.neon
as well) in a WordPress plugin directory as well as the project root, and it doesn't appear to be loading them.
Thank you!
claygriffiths We don't have docs yet. Most probably we fail to parse the .neon content due to some unexpected whitespace or indentation.
May I ask you to try simplifying the phpstan.neon
file? Maybe the editor will load it then. I guess our reader needs some improvements.
claygriffiths I've found a bug in .neon
file parser - working on it.
JakubMisek Sounds good!
As an example, here's what we have in our phpstan.neon
in one plugin.
parameters:
level: 9
checkGenericClassInNonGenericObjectType: false
paths:
- gs-product-configurator.php
- class-gs-product-configurator.php
- includes/
scanDirectories:
- ../gravityforms
- ../woocommerce
excludePaths:
analyse:
- includes/third-party
ignoreErrors:
# gf_apply_filters only specifies two params.
- '#Function gf_apply_filters invoked with \d+ parameters, 2 required.#'
typeAliases:
GFFeed: '''
array{
id: int,
form_id: int,
meta: array<string, mixed>,
is_active: 0|1,
addon_slug: string,
}
'''
GSPCFeed: '''
GFFeed & array{
meta: array<string, mixed> & array{
display_price: string,
item_meta_display: string,
item_meta_display_template: string,
},
}
'''
claygriffiths thank you, I'll add it into our unit tests!
Preparing pre-release with the updated .neon
parser.
It's working well! Thanks a ton, @JakubMisek.
claygriffiths great! thank you very much for your patience, and all the feedback!
If there will be anything to improve, please feel free to point it out.
Hey @JakubMisek, a quick check-in on this: it has been working great!
So much so that we'd like to start moving our type aliases into a PHPStan extension. While being compatible with https://github.com/phpstan/extension-installer is probably a stretch, it'd be cool if DEVSENSE could support includes
: https://phpstan.org/config-reference#multiple-files