Do not use absolute paths for storing found plugins

[spawnia]

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 https://github.com/phpstan/phpstan/issues/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?

[hws47a]

I'm having the same issue, so I would be happy to implement the fix if somebody will help me with details.

[ondrejmirtes]

Hi, I'm fine if this utility isn't usable by everyone. It can afford to only solve the happy path for its users. The only thing it does is to save typing a few lines in your phpstan.neon.

I'm not comfortable with including relative paths. So unless someone comes up with a safe solution, this will remain open.

[zorac]

Hi, would using something like the below be acceptable, so it's using paths relative to GeneratedConfig.php, but not dependant on the current working directory?

    'install_path' => __DIR__ . '/../../../phpstan/phpstan-phpunit',

[cjunge-work]

@zorac I've created a PR to implement your suggestion. I based it on the vendor dir, though. Any thoughts appreciated!

[arnaudgoulpeau]

I know we are in a specific case, but for people having this issue when

• using a php container
• using a separate composer container

@ondrejmirtes told us to modify the composer vendor path (https://github.com/phpstan/extension-installer/pull/23#issuecomment-590922447), but the simplest solution for us was to update the volume mount.

So make sure your composer container working-dir is the same as your php container working dir :

our docker-compose example :

composer:
    ...
    working_dir: "/var/www/html"

php:
    volumes:
      - "./app:/var/www/html/app"
      - "./bin:/var/www/html/bin"
     ...

This conf allowed us to use the extension-installer without anything else.

[neclimdul]

ugh, I'd been working around this but just updated phpstorm today and it detects phpstan and its errors for days everytime anything changes and it rechecks the config... what do we need to fix this?

[ondrejmirtes]

@neclimdul Not sure if it's related to this issue, but I'd need more details, your description isn't sufficient.

[neclimdul]

its the same. development happens in container(lando) and phpstorm happens locally. paths are different.

[olvlvl]

Same as @neclimdul, our services run in containers but PHPStan integration with PhpStorm runs locally, and the integration is so nice, it's difficult to live without. Right now I'm editing install_path so it runs from the CWD. I was using Composer\Util\Filesystem::findShortestPathCode in my framework to create a short relative path, but there are two challenges with extension-installer: $data is rendered with var_export, so no PHP code possible; the data is rendered as a constant, so no expression is allowed. If we'd like to improve this, first we'll have to generate getters instead of constants.

[ondrejmirtes]

Alright, so I fixed it in a straightforward way: https://github.com/phpstan/extension-installer/commit/66c7adc9dfa38b6b5838a9fb728b68a7d8348051

You'll be able to use it if you meet these dependencies:

• phpstan/extension-installer 1.1.0 (this project, already released)
• phpstan/phpstan 0.12.62 (not out yet, but you can try out dev-master)

Thanks everyone :)

[ondrejmirtes]

Alright, PHPStan 0.12.62 is out!

Starting with phpstan/phpstan 0.12.62 and phpstan/extension-installer 1.1.0, relative paths to extension configs are used. This allows the generated config to be moved across filesystems, for example from a host system to a Docker container.

[github-actions[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.