[1.x] Add configurable PHP and Composer paths

[aivis]

Summary

This PR adds support for configurable PHP and Composer binary paths through two new configuration options:

• boost.default_php_bin - Configure the PHP binary path (defaults to php)
• boost.default_composer_bin - Configure the Composer binary path (defaults to composer)
• It does not change the existing behaviour in any way unless the new config keys are used

Motivation

Many developers use containerized or specialized development environments like Lando, DDEV, Nix, Homebrew, or custom Docker setups where PHP and Composer binaries are not available at the standard php and composer paths:

• Lando commands need to be prefixed with lando (lando composer etc.).
• Running multiple PHP versions side-by-side (/usr/local/bin/php8.3)
• Using Homebrew-installed PHP with non-standard paths
• Working in environments where the system PATH doesn't include the desired PHP/Composer binaries

This feature allows developers to configure their environment and have Boost generate correct commands for their setup.
I did not add these config keys to the config/boost.php file as it seems to be the case for other custom config keys.

Changes

• CodeEnvironment::getPhpPath() - Now reads from config('boost.default_php_bin', 'php') when not forcing absolute paths
• GuidelineAssist::composerCommand() - Now reads from config('boost.default_composer_bin', 'composer') when not using Sail
• GuidelineAssist::artisan() - Now uses the configured PHP binary for artisan commands when not using Sail
• Adds tests matching existing patterns to cover the introduced changes

Usage

Add the following to your config/boost.php file:

return [
    // ... existing config

     'commands' => [                                                                                                                                                                                                         
         'php' => env('BOOST_PHP_BIN', 'php'),                                                                                                                                                                               
         'composer' => env('BOOST_COMPOSER_BIN', 'composer'),                                                                                                                                                                
     ],      
];

[aivis]

I'm aware of #419 , however, I think this more aligns with the existing approach (config variables are used in other places), later (if necessary) can be extended for NPM and other commands, and allows developers to have their settings in the boost config file.

[pushpak1300]

  'commands' => [                                                                                  
      'php' => 'php',                                                                              
      'composer' => 'composer',                                                                    
  ],      

Do you think config name like this is more readable instead of default_php_bin ?

[aivis]

My reasoning for the default prefix is that these configuration variables do not guarantee specific outcome.
Other high-level conditionals also affect the result, such as:

• $this->useAbsolutePathForMcp() || $forceAbsolutePath
• $this->config->usesSail

And they have higher precedence.

These variables simply act as overrides or modifiers for the default bin paths.

[aivis]

That said, I don't mind either way and I've made the necessary changes. It is probably a better config structure this way.

[fritz-c]

Should some default config be added to https://github.com/laravel/boost/blob/1.x/config/boost.php to document this?

Also, could the existing boost:install command be tweaked to allow a user to modify these values at onboarding time?

[aivis]

Should some default config be added to https://github.com/laravel/boost/blob/1.x/config/boost.php to document this?

Also, could the existing boost:install command be tweaked to allow a user to modify these values at onboarding time?

Adjusted the boost.php file.

On the second point, I consider that out of scope. It could cause more confusion than help (?) and not everything is configurable through setup anyway.

[aivis]

@fritz-c @pushpak1300 Thanks for the reviews! I think the PR now covers all binaries + vendor bin prefix.

[pushpak1300]

Thanks @aivis i will probably take a look today and try to merge.

[james2doyle]

I think it would be nice if it detected a herd.yml and ask if php and composer should be prefixed. But it sounds like that can be a new PR once this is in right?

[smares]

Please consider #429 and that having the project set up with Sail does not mean every command needs to run via Sail, especially when using devcontainers where commands are ran "natively" without any prefix.

[pushpak1300]

@aivis i will port this changes to main branch also. thanks for all the help.