phpstan / extension-installer Goto Github PK
View Code? Open in Web Editor NEWComposer plugin for automatic installation of PHPStan extensions.
License: MIT License
Composer plugin for automatic installation of PHPStan extensions.
License: MIT License
Hi, I'm updating a drupal site and came across the following dependency issue
phpstan/extension-installer 1.4.0 requires composer-plugin-api ^2.6.0 -> found composer-plugin-api[2.3.0] but it does not match the constraint.
- drupal/core-dev 10.2.7 requires phpstan/extension-installer ^1.1 ->
I have limited access to composer/composer plugins on the target system (Pantheon, php 8.1), which is running Composer version 2.5.8 2023-06-09 17:13:21
, my local system with an older composer version (2.5.5 2023-03-21 11:50:05
) doesn't have this issue
I tried adding a requirement for composer-plugin-api:^2.6
, but it seems to insist on 2.3:
Root composer.json requires composer-plugin-api ^2.6, found composer-plugin-api[2.3.0] but it does not match the constraint.
I searched the documentation and site, but didn't really find specifics around the composer plugin api.
For now, I'm using composer require "phpstan/extension-installer:1.0 - 1.3" --dev
.
Is there any documentation around the version of composer-plugin-api
for the extension installer?
Thanks, Sandra.
Hi,
Recently I published a package that will help you find all the installed packages in your projects.
The README file has examples on how to use it and more explanations on how it works.
The use case of this library is that I was looking for a way to retrieve all the installed packages directories. At first I was using symfony/finder, but it was heavy and very slow. Then, I had the idea to "cache" those data through a Composer plugin, this is how I had the idea of this package.
On top of adding functionalities to get the package directories, I did the same kind of stuff for the package types and for the packages themselves.
In this particular use case, you can use it to directly get packages of type 'phpstan-extension' just by using:
Types::phpstanExtension();
or
Types::get('phpstan-extension');
Feel free to test it, if you are going to use it in your project and let me know how it goes, feedback is appreciated.
Examples of class that this package will generate:
Thanks!
In our setup we use just few handpicked rules from some opinionated extensions. When we use extension installer all rules from these extensions are included. It would ne nice to have option to disable loading of certain extensions.
Hi there, and first of all, thank you for this awesome work!
When I wanted to propose a new pull request, I found that your script is following a coding standard that is not in compliance with the PSR-2 nor the incoming PSR-12.
Is this something you did by choice (to not rely on those PSRs)?
On other hand, if you're interested in to follow those standards (and being more strict by continuing to follow your current rules that are not in conflict with PSRs), I can provide a PR for that.
Thanks again
Starting with composer 2.2 all plugins are disabled by default and manual confirmation to enable them is required.
This is a feature request to drop the config generation via composer plugin by generating the config from phpstan directly on runtime like:
if (class_exists(\PHPStan\ExtensionInstaller\GeneratedConfig::class)) {
$config = \PHPStan\ExtensionInstaller\GeneratedConfig::getConfig();
// add generated config to phpstan
// ...
}
I'm facing a problem with Scrutinizer and this package requiring "composer-plugin-api": "^1.1". Have a look here: https://scrutinizer-ci.com/g/juliangut/json-api/inspections/b2ee72d5-7046-4c60-afe2-aee3475ab8bb
Others have face this situation before, such as symfony/thanks#36
It seems it has to do with composer version so no problem with the package
Anyway I've to ask why ^1.1, couldn't a lower requirement be enough? I've no experience with composer plugin system so far
In rectorphp/rector-src#4769 rector dropped automatic loading of PHPStan extensions, because it seems to much work to maintain the feature.
As of this linked PR one needs to manually register PHPExtensions to rectors' internal PHPStan , so it will utilize the additional sources of type-knowledge. Its a pity that we have the luxury of the Extension Installer for PHPStan, but don't have it anymore for rector - as manually keeping a list of extensions is a maintenance pain.
my local testing suggests, to get it running again I need to add a phpstan.neon to rector which contains a includes:
config with a php file like:
<?php
declare(strict_types=1);
use PHPStan\Command\InceptionNotSuccessfulException;
use PHPStan\ExtensionInstaller\GeneratedConfig;
$additionalConfigFiles = [];
if (class_exists('PHPStan\ExtensionInstaller\GeneratedConfig')) {
$generatedConfigReflection = new ReflectionClass('PHPStan\ExtensionInstaller\GeneratedConfig');
$generatedConfigDirectory = dirname($generatedConfigReflection->getFileName());
foreach (GeneratedConfig::EXTENSIONS as $name => $extensionConfig) {
foreach ($extensionConfig['extra']['includes'] ?? [] as $includedFile) {
if (!is_string($includedFile)) {
$errorOutput->writeLineFormatted(sprintf('Cannot include config from package %s, expecting string file path but got %s', $name, gettype($includedFile)));
throw new InceptionNotSuccessfulException();
}
$includedFilePath = null;
if (isset($extensionConfig['relative_install_path'])) {
$includedFilePath = sprintf('%s/%s/%s', $generatedConfigDirectory, $extensionConfig['relative_install_path'], $includedFile);
if (!is_file($includedFilePath) || !is_readable($includedFilePath)) {
$includedFilePath = null;
}
}
if ($includedFilePath === null) {
$includedFilePath = sprintf('%s/%s', $extensionConfig['install_path'], $includedFile);
}
if (!is_file($includedFilePath) || !is_readable($includedFilePath)) {
$errorOutput->writeLineFormatted(sprintf('Config file %s does not exist or isn\'t readable', $includedFilePath));
throw new InceptionNotSuccessfulException();
}
$additionalConfigFiles[] = $includedFilePath;
}
}
}
return ['includes' => $additionalConfigFiles];
this means I copied the logic from CommandHelper
could we move this part into a new method, so I can call it from my php-file which gets loaded via includes:
instead of duplicating the logic?
No response
I am having a closed source phpstan plugin, declared as "type": "phpstan-extension",
(composer.json) and it declares a
"extra": {
"phpstan": {
"includes": [
"packages/phpstan-rules/config/best-practices.neon"
]
}
},
the plugin itself is scanned via phpstan and phpstan is configured to use the plugins itself to scan itself.
while running composer install I am running into a InvalidArgumentException
:
> post-install-cmd: PHPStan\ExtensionInstaller\Plugin->process
[InvalidArgumentException]
$from (C:\dvl\Workspace\php-clx-symplify\vendor\phpstan\extension-installer\src) and $to (vendor/plugins/rocket) mu
st be absolute paths.
Exception trace:
() at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/src/Composer/Util/Filesystem.php:453
Composer\Util\Filesystem->findShortestPath() at C:\dvl\Workspace\php-clx-symplify\vendor\phpstan\extension-installer\src\Plugin.php:120
PHPStan\ExtensionInstaller\Plugin->process() at n/a:n/a
call_user_func() at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/src/Composer/EventDispatcher/EventDispatcher.php:192
Composer\EventDispatcher\EventDispatcher->doDispatch() at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/src/Composer/EventDispatcher/EventDispatcher.php:119
Composer\EventDispatcher\EventDispatcher->dispatchScript() at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/src/Composer/Installer.php:372
Composer\Installer->run() at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/src/Composer/Command/InstallCommand.php:139
Composer\Command\InstallCommand->execute() at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/vendor/symfony/console/Command/Command.php:245
Symfony\Component\Console\Command\Command->run() at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/vendor/symfony/console/Application.php:835
Symfony\Component\Console\Application->doRunCommand() at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/vendor/symfony/console/Application.php:185
Symfony\Component\Console\Application->doRun() at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/src/Composer/Console/Application.php:336
Composer\Console\Application->doRun() at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/vendor/symfony/console/Application.php:117
Symfony\Component\Console\Application->run() at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/src/Composer/Console/Application.php:131
Composer\Console\Application->run() at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/bin/composer:83
require() at C:\ProgramData\ComposerSetup\bin\composer.phar:29
when running composer install -vvv
Im using symfony 6.4 and phpstan and get an error on my prod environment:
_Installing dependencies from lock file (including require-dev)
Verifying lock file contents can be installed on current platform.
Your lock file does not contain a compatible set of packages. Please run composer update.
Problem 1
- phpstan/extension-installer is locked to version 1.4.0 and an update of this package was not requested.
- phpstan/extension-installer 1.4.0 requires composer-plugin-api ^2.6.0 -> found composer-plugin-api[2.3.0] but it does not match the constraint._
Can anyone do something with this?
The usage of absolute paths causes issues when the execution context of the project changes, e.g. when mounting into a container or simply moving the project directory.
Examples of breakage: #5 phpstan/phpstan#2269
Let's explore ways to work around that issue. I think the installation target of the PHPStan binary inside of vendor
should be deterministic, can we just use a path relative to that?
i've installed this plugin and somehow it's also running when i run my website outside phpstan.
when i install this package, i get an error that it cand find the PhpDocParser and that it needs to added to the use statement but it's already there.
vendor/symfony/property-info/Extractor/PhpStanExtractor.php on line 67
when i remove this package my website works again.
i've also added the includes again in the phpstan.neon file and phpstan is still working with the phpstan extensions
Hi,
I installer phpstan/extension-installer
and updated my configuration file that now looks like this:
includes:
- vendor/phpstan/phpstan/conf/bleedingEdge.neon
- phpstan-baseline.neon
When running the analyse on Github, it works as before and now error is reported.
But on my local env, it reports lots of defects that are all related to the use of deprecations.
When adding back phpstan/phpstan-deprecation-rules/rules.neon
, it works fine on local but fails on Github arguing the extension is already installed (see this).
I removed and reinstalled all var
, vendors
and *.lock
files, but leads to the same result.
Is there anything I missed to run on my local env?
Hi,
I have the following constellation:
composer global require ...
)My problem is as follows:
composer install
locally in the project.This is because the extension installer re-generates the GeneratedConfig
on composer install
, and because there are no extensions installed locally, the config is now empty. This leads to some code not being correctly interpreted because the extensions are ignored.
Is there anything I need to do, or do you have other advice? Thanks! :-)
This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.
These updates have all been created already. Click a checkbox below to force a retry/rebase of any.
composer.json
php ^7.2 || ^8.0
phpstan/phpstan ^1.9.0
composer/composer ^2.0
php-parallel-lint/php-parallel-lint ^1.2.0
phpstan/phpstan-strict-rules ^0.11 || ^0.12 || ^1.0
e2e/ignore/composer.json
e2e/integration/composer.json
.github/workflows/build.yml
actions/checkout v4
shivammathur/setup-php v2
actions/checkout v4
actions/checkout v4
shivammathur/setup-php v2
actions/checkout v4
shivammathur/setup-php v2
.github/workflows/create-tag.yml
actions/checkout v4
WyriHaximus/github-action-get-previous-tag v1
WyriHaximus/github-action-next-semvers v1
rickstaa/action-create-tag v1
rickstaa/action-create-tag v1
.github/workflows/integration-tests.yml
actions/checkout v4
shivammathur/setup-php v2
actions/checkout v4
shivammathur/setup-php v2
.github/workflows/lock-closed-issues.yml
dessant/lock-threads v5
.github/workflows/release-toot.yml
cbrgm/mastodon-github-action v2
.github/workflows/release-tweet.yml
Eomm/why-don-t-you-tweet v1
.github/workflows/release.yml
actions/checkout v4
metcalfc/changelog-generator v4.3.1
actions/create-release v1
When using --no-dev
flag, Composer still tries to work with Installer. However, when Installer is installed as dev dependency, there are no related files and Composer fails.
file_put_contents(//vendor/phpstan/extension-installer/src/GeneratedConfig.php): failed to open stream: No such file or directory
How to reproduce:
composer install
composer install --no-dev
When dockerizing my application I first COPY
just composer.json
and composer.lock
, then I have a RUN
layer with composer install
and only then copy the rest of the application. This is good for caching the layer with all the installed packages.
Unfortunately since I'm using symfony/flex
I have to run composer install
with --no-scripts
because otherwise flex
would fail when I don't have the application files yet (missing configuration for some bundles).
This of course disables phpstan/extension-installer
as well so I'd like to run it manually somehow. Is there a way to do that?
I am trying to add phpstan extension support to a few libraries we use internally, and am wondering if they're being detected / loaded correctly.
At the end of the composer update
output I'm getting:
Symfony operations: 1 recipe (20dfc4e46c7b7d0a930db3febc76557f)
- Unconfiguring phpstan/extension-installer (>=1.0.5): From auto-generated recipe
phpstan/extension-installer: Package not found (probably scheduled for removal); extensions installation skipped.
These are the versions I had before:
phpstan/extension-installer 1.0.5
phpstan/phpstan 0.12.43
phpstan/phpstan-deprecation-rules 0.12.5
phpstan/phpstan-doctrine 0.12.20
phpstan/phpstan-strict-rules 0.12.5
phpstan/phpstan-symfony 0.12.8
And these are the versions I have now (notice that phpstan/extension-installer
is gone):
phpstan/phpstan 0.12.50
phpstan/phpstan-deprecation-rules 0.12.5
phpstan/phpstan-doctrine 0.12.21
phpstan/phpstan-strict-rules 0.12.5
phpstan/phpstan-symfony 0.12.9
We have noticed that disabling phpstan/extension-installer/
plugin in the right way ™️ and running composer i
or composer update --lock
or any other command does not regenerate and flush out the generated file at vendor/phpstan/extension-installer/src/GeneratedConfig.php
.
composer root package requires manual include
.
all extentions exported using composer.json's extra
section must be used for the current/root repo too
During plugin installation, there are some absolute paths being stored inside configuration/autoloader. This causes errors if you install a plugin inside Docker but then later want to use your app outside Docker.
Or if you rename the project folder, or your home folder, whatever. I think you shouldn't be using absolute paths at all - they all should be relative to the project root.
Thanks for this feature.
For phpstan extension developers, adding the phpstan
extra key should be consider a breaking change? As we are going to auto-wire extensions and possible breaking people deployments?
Hello, I'm considering adding an extension.neon in an existing library to help recognizing methods available via __call
/ __callStatic
PHPStan can't recognize.
Extension's composer package type has to be set to phpstan-extension for this plugin to be able to recognize it.
The library itself is not a PHPStan extension (so I can't set type to phpstan-extension). But I would like than my library users who also use PHPStan get those methods recognized by PHPStan the easier way.
Creating an other package to handle the extension.neon + 1 small file seems overkill too.
And finally, I think having a extra.phpstan
property is enough to recognize a library that includes PHPStan files. Why requiring this additional phpstan-extension
flag?
Thanks.
Hi,
This is a know problem that you can't not enable a package if you install both the extension and extension installer. For example here: https://github.com/phpstan/phpstan-strict-rules#with-extension-installer I'd like to enable just couple of rules not the all of them.
What I'd like to suggest is the ability to not auto install some extensions. This can be done for example like so in users composer.json
:
"extra": {
"phpstan": {
"dont-install": [
"phpstan/phpstan-strict-rules"
]
}
}
So phpstan/extension-installer
can check if this config exists in users composer.json
and if the PHPStan extension is in the list, it'll not be automatically installed.
I got the idea from Laravel.
What do you think?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.