phpstan / extension-installer Goto Github PK

Composer plugin for automatic installation of PHPStan extensions.

License: MIT License

PHP 92.15% Makefile 7.85%

extension-installer's Introduction

PHPStan - PHP Static Analysis Tool

PHPStan focuses on finding errors in your code without actually running it. It catches whole classes of bugs even before you write tests for the code. It moves PHP closer to compiled languages in the sense that the correctness of each line of the code can be checked before you run the actual line.

Read more about PHPStan »

Try out PHPStan on the on-line playground! »

Documentation

All the documentation lives on the phpstan.org website:

PHPStan Pro

PHPStan Pro is a paid add-on on top of open-source PHPStan Static Analysis Tool with these premium features:

Web UI for browsing found errors, you can click and open your editor of choice on the offending line.
Continuous analysis (watch mode): scans changed files in the background, refreshes the UI automatically.

Try it on PHPStan 0.12.45 or later by running it with the --pro option. You can create an account either by following the on-screen instructions, or by visiting account.phpstan.com.

After 30-day free trial period it costs 7 EUR for individuals monthly, 70 EUR for teams (up to 25 members). By paying for PHPStan Pro, you're supporting the development of open-source PHPStan.

You can read more about it on PHPStan's website.

Code of Conduct

This project adheres to a Contributor Code of Conduct. By participating in this project and its community, you are expected to uphold this code.

Contributing

Any contributions are welcome. PHPStan's source code open to pull requests lives at phpstan/phpstan-src.

extension-installer's People

Contributors

Stargazers

Watchers

extension-installer's Issues

Question: adding composer extra for should be a breaking change?

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?

composer.json's `extra` section must be honored also for root-package

Currently state

composer root package requires manual include.

Expected state

all extentions exported using composer.json's extra section must be used for the current/root repo too

Ability to ignore certain extensions

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.

Compliance with PSR-2 and/or PSR-12?

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

add composer 2 compatibility

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

This repository currently has no open or pending branches.

Detected dependencies

composer

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-actions

.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

Check this box to trigger a request for Renovate to run again on this repository

App doesn't work outside Docker if plugin is installed inside it and vice versa

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.

composer-plugin-api version question

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

Disabling the plugin does not flush out generated config in an existing dev environment

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.

Question: Is there a way to list extensions?

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.

The installer doesn't add the generated config to Git

But that seems to be by design: c36c32c

This causes a bit of a headache when the vendor dir is in Git as the src/GeneratedConfig.php file is .gitignore'd so it's not added, silently.

This should at least be documented (done in #11).

Automatic PHPStan extension loading in rector

Feature request

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?

Did PHPStan help you today? Did it make you happy in any way?

No response

Do not use absolute paths for storing found plugins

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?

Composer is trying to use extension-installer when using --no-dev flag

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

Extension installer is also execute when not using phpstan

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

Drop composer plugin usage in favor of generating/use the config from phpstan directly

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
    // ...
}

Config generation on global installation

Hi,

I have the following constellation:

PHPStan is installed globally (composer global require ...)
My project is of course "local" and I use PHPStan there.

My problem is as follows:

I run PHPStan after setup, and results are as expected.
Then I run composer install locally in the project.
When I run PHPStan again, the scan fails.

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! :-)

Extension missing on local, but not on Github Actions

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?

Why type: phpstan-extension is mandatory?

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.

InvalidArgumentException on post-install-cmd: `PHPStan\ExtensionInstaller\Plugin->process`

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

Evaluate drupol/composer-packages - A Composer helper classes for finding installed packages/types/installation directories

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!

Add ability to not install extensions

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?

Bug?: `composer update` removed the package

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

Is it possible to run this plugin manually?

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?