[BUGFIX] Keep PhpStorm from indexing the tool PHARs

[oliverklee]

PHPUnit is the only tool for which we would like PhpStorm to index
the PHAR (so that it knows the PHPUnit classes exist). For all other
tools, indexing the PHARs would only slow PhpStorm down (and possibly
create warnings about classing existing multiple times).

[JakeQZ]

This will break the development environment on Windows, which depends on file extensions to know what program to use to run an executable.

I can't immediately think of a workaround or alternative solution...

[JakeQZ]

I'll checkout the branch and look into it later. I know that PHIVE also generates batch files for Windows - maybe Windows will prefer those to the file without an extension...

[JakeQZ]

I know that PHIVE also generates batch files for Windows - maybe Windows will prefer those to the file without an extension...

Yes, Windows will run a batch file if one exists with a .bat extension and the same base name as the requested extension-less file. I don't know if it's possible to get PHIVE to generate these when run on non-Windows, but if not, they can be manually created.

The same content will do for all of them:

@echo off
php "%~dpn0" %*

It does not matter if the line endings are Windows or UNIX, or if the last line has one. There'll need to be one for each tool without a file extension, i.e. psalm.bat, phpmd.bat, etc.

The exact content generated by PHIVE is tool-specific, e.g. for Psalm

@echo off
php "%~dp0psalm" %*

%~...0 expands based on the command part of the command line as described here, so dp = drive and path and dpn = drive, path and filename without extension.

Without such batch files, the tools without a file extension do indeed fail to run:

> "./tools/phpmd" src text config/phpmd.xml
'".\tools\phpmd"' is not recognized as an internal or external command,
operable program or batch file.
Script "./tools/phpmd" src text config/phpmd.xml handling the ci:php:md event returned with error code 1

[oliverklee]

@JakeQZ Does work in Windows for you if we changed every tool-related Composer command to use the @php prefix, e.g., like this:

"ci:php:sniff": "@php \"./tools/phpcs\" config src tests",

[JakeQZ]

"ci:php:sniff": "@php \"./tools/phpcs\" config src tests",

That would indeed work :)

While here, I wonder if were are using PHIVE in the right/recommended way. I.e. should we be storing the .phars under version control at all? We don't put the contents of the vendor directory from Composer under version control. And isn't the phive.xml at least partly analogous to the composer.lock file - though part of it is analogous to composer.json and would be needed under version control, with the only other way I can think of handling it being a script with a series of PHIVE commands specifying the required versions to install.

Feedback from phar-io/phive#296 suggests we have an "interesting use case". However feedback from phar-io/phive#295 indicates PHIVE currently does not support installing a version necessarily compatible with the calling environment.

Possibly a separate issue to come back to when it becomes more clear what the 'best practice' is...

[oliverklee]

Let's see what the rest of the PHP developer crowd thinks. :-)

I have created a Twitter poll for this: https://twitter.com/oliklee/status/1380082284200595457

[JakeQZ]

This is only needed for the CI build server, so it's OK.