laravel
Run composer install in dev container
Today, starting a dev container using curl -s "https://laravel.build/example-app?with=mysql,redis&devcontainer" | bash (or any version with a dev container I assume), it works great. However, if I push that repo to GitHub and clone it back down, the dev container will not start.
That happens because the docker-compose.yml refers to ./vendor, which of course doesn't exist (yet).
I have done some testing on my end, and running this command before creating the dev container ensures that ./vendor/laravel/sail/runtimes/8.3(/Dockerfile) exists before trying to create the container.
The command is from https://laravel.com/docs/11.x/sail#installing-composer-dependencies-for-existing-projects
For this to work, you would need to add the following to the .env file:
WWWGROUP=1000
WWWUSER=1000
This PR, or something like it, aims to make it easier for new developers to get started with the Laravel dev container.
Note: I am completely new to Laravel and somewhat new to Docker. If this is not the fix here, please let me know.
Right now the command uses php83. I am not sure how that should be changed or if it can be dynamic.
It could also be commented out initially.
@leonlarsson Does this make dev containers work for Laravel? Because I’ve always liked the thought of using them but could never get them to work, I think because of the issues you describe (you need the Sail package instead by Composer, but you don’t have that package—or any Composer package—installed in a fresh checkout).
@leonlarsson Does this make dev containers work for Laravel? Because I’ve always liked the thought of using them but could never get them to work, I think because of the issues you describe (you need the Sail package instead by Composer, but you don’t have that package—or any Composer package—installed in a fresh checkout).
Dev containers also work without this, but I believe this makes it significantly more user-friendly. Without this, you would need to run this command manually, outside of the dev container (because the container can only start if it already has Sail under ./vendor).
You could try it locally by adding my addition to your dev container config and see if it helps your workflow
It seems like there are not a lot of people having the same "issue", so this could probably be closed
I've had the same issue when creating a project and then trying to have other developers be able to build it. Instead of having composer install built into the initialization, my fix was to copy the necessary stub/runtime files into the project directory, scoped to the particular application (i.e. PHP config files in .docker/php, MariaDB in .docker/mariadb, etc.), and then updating docker-compose.yml to point to those instead.
Since I work in an environment where we juggle different Laravel projects with different PHP versions, requiring developers have specific PHP versions installed at the system level isn't practical or feasible. Doing it this way means that some .env changes and docker compose up are the only things necessary to get started.
I have this problem every time I need to share a devcontainer project. Currently I use the manual way:
This is from the Laravel documentation (11x), this part was removed in 12x, I don't know why.
I have this problem every time I need to share a devcontainer project. Currently I use the manual way:
This is from the Laravel documentation (11x), this part was removed in 12x, I don't know why.
It's business. Herd ;)
I have this problem every time I need to share a devcontainer project. Currently I use the manual way:
This is from the Laravel documentation (11x), this part was removed in 12x, I don't know why.
Taylor has replied here
https://github.com/laravel/docs/pull/10357#issuecomment-2836047064
