Skip to content

Add --target option to specify Laravel version to install #383

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

miclaus
Copy link
Contributor

@miclaus miclaus commented Jan 3, 2025

I've added a --target option to allow developers to specify which version of Laravel they want to install. This feature has been frequently requested over the years (see #229 in 2022, #250 in 2023, #229 again in 2023, and #319 (comment) in 2024).

Recently, I personally encountered the need for this feature when working with a client's server that runs multiple PHP applications that are dependent on PHP 8.1. The version of PHP cannot be changed, and the client is not willing to pay for another server, making it necessary to install Laravel 10 rather than the latest version.

What's the alternative? The documentation doesn't mention any (anymore). As of Laravel 11, documentation on installing with composer create-project was removed. Docs is pointing to the laravel installer, which everyone I believe, myself included, enjoys using.

This PR would allow:

laravel new example-app --target=^10.0
Also consider "Docker Installation using Sail"

The laravel.build (sail-server) is also affected by the absence of this feature, since it relies on the Laravel installer behind the scenes. To understand how the script creates a new project with an older Laravel version, you'd need to inspect not just the laravel.build script, but also the Laravel installer's code. This adds unnecessary complexity.

"Docker Installation using Sail" is recommended like so:

curl -s "https://laravel.build/example-app" | bash

Older Laravel docs (e.g. see Docker Installation Using Sail) don't mention that this command installs the latest Laravel version. This leads to confusion (or is even left unnoticed) when developers expect to install the version they are currently reading about in the documentation.

I've already prepared a solution for myself (see changes in miclaus/sail-server#2 and miclaus/sail-server#3) for the sail-server that adds a version query parameter for passing the --target option to the Laravel installer. This change could easily be added for older docs. Together with this PR's feature, the following would be possible for e.g. Laravel 10:

curl -s "https://laravel.build/example-app?version=10" | bash

This PR adds flexibility without altering the default experience, and would be particularly developer-friendly for those working with legacy systems or in resource-constrained environments.

I totally agree that installing the current Laravel version should be recommended. Still, IRL sometimes we need to work with what we have, and this change would simplify the process a lot.

Please consider this. I'm sure we can figure something out.

- remove version restriction tests
- add dev and target options validation for interactive mode (otherwise the exception will be thrown only after the interactive part, if there's a conflict)
@miclaus miclaus force-pushed the feature/add-target-option branch from d3926fd to ccd0a63 Compare January 3, 2025 23:14
@taylorotwell
Copy link
Member

Thanks for your pull request to Laravel!

Unfortunately, I'm going to delay merging this code for now. To preserve our ability to adequately maintain the framework, we need to be very careful regarding the amount of code we include.

If applicable, please consider releasing your code as a package so that the community can still take advantage of your contributions!

@miclaus
Copy link
Contributor Author

miclaus commented Jan 6, 2025

@taylorotwell Thank you for taking the time to review my PR!

Honestly, this change would significantly improve the quality of life for Laravel developers, especially those working in constrained environments.

It's a feature frequently requested by the community and introduces a just tiny portion of simple logic that actually requires one less test to maintain.

Could you please let me know if there are specific concerns or further adjustments I could make to align this PR with the framework's goals? I'd be happy to help.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants