Support custom Composer vendor directory locations

[zhyian]

Please check if the PR fulfills these requirements

• The commit message follows our guidelines
• Tests for the changes have been added (for bug fixes/features)
• Docs have been added/updated (for bug fixes/features)

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

Feature

What is the current behavior? (You can also link to an open issue here)

The workflows hardcode ./vendor/bin/ as the path to the binary files. Projects that configure a custom vendor-dir in composer.json (e.g. public/wp-content/vendor/) cannot use these workflows.

What is the new behavior (if this is a feature change)?

Tools are now executed using the binary path resolved dynamically via composer config bin-dir, instead of the hardcoded ./vendor/bin/. This means workflows will automatically respect any custom bin-dir configured in the project's composer.json, supporting setups where the vendor directory is not in the repository root (e.g. public/wp-content/vendor).

Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)

No

Other information

[tyrann0us]

issue:

Thank you for the PR! As it is right now, it is not merge-ready because all workflows that execute Composer libraries would need to be updated, and so would the documentation.

Anyway, I would like to request a different approach by having Composer do the vendor, or rather bin directory resolving:

- name: Run PHP_CodeSniffer
  run: ./$(composer config bin-dir)/phpcs ${{ inputs.PHPCS_ARGS }}

This has multiple benefits over the current approach, IMO:

• Does not require any changes to calling workflows.
• Does not require any documentation updates.
• DRY; no repetition of paths in composer.json and workflow files.
• Uses bin-dir to support composer.json configs where vendor-dir and/or bin-dir is set (falls back to whatever vendor resolves to + /bin).

Please test this approach and apply it to all corresponding workflow files if it works. Thank you!

[tyrann0us]

Does not require any documentation updates.

I'm sorry, this was a lie. 🙈 I realized that in https://github.com/inpsyde/reusable-workflows/blob/main/docs/php.md, we state multiple times, "It does so by executing the binary in the ./vendor/bin/ folder." This is potentially no longer accurate, and I would simply remove all occurrences of that sentence.

Also, can you apply the change to the new Deployer workflow https://github.com/inpsyde/reusable-workflows/blob/main/.github/workflows/deploy-deployer.yml added in #227?

(I know this is still a draft PR. 🙂)

[zhyian]

Thanks Philipp.

The original issue was about projects where the project's vendor directory is in a non-standard location (e.g. public/wp-content/vendor). In deploy-deployer.yml, Deployer is always intentionally installed under ./deployment/ via the ramsey/composer-install step with working-directory: ./deployment, so its vendor location is fixed and known. Do you think we still need to apply the same fix here?

[tyrann0us]

[…] Deployer is always intentionally installed under ./deployment/ via the ramsey/composer-install step with working-directory: ./deployment, so its vendor location is fixed and known.

Not really. working-directory: ./deployment simply instructs ramsey/composer-install to look for a composer.json file in that folder. Unless I'm overlooking something, that composer.json file can potentially also include a vendor-dir or bin-dir config, so the change would also be required for this workflow.
(Unsure if the composer config bin-dir command would realize when /composer.json doesn't have that directive, but deployment/composer.json has; we should test this. 🙂)

[zhyian]

That's right, thanks!
The root /composer.json is irrelevant once we cd deployment - composer only reads the composer.json in the current directory. I tested it locally with the same folder structure: when /composer.json has no bin-dir set, composer config bin-dir returns vendor/bin, and when deployment/composer.json has a custom bin-dir, it correctly returns that value.

[tyrann0us]

Thank you for working on this! 💪🏽 PR title and description no longer match the latest state, but this doesn't stop me from approving. 😉