Remove --no-scripts from PHP composer install command

[Spirit55555]

--no-scripts prevents pre-install-cmd and post-install-cmd events from running.

I see no reason to prevent this and I had to add a workaround to my own applications, due to this.

It was added as part of this commit: 1547fa7

[iloveitaly]

@Spirit55555 I'm not familiar with the PHP ecosystem, unfortunately! So you'll have to walk me through this.

• My understanding is some pre/post install scripts require access to the runtime environment, not just a build environment (possible database access, etc). Does this sound right to you?
• What workaround did you end up using in your app?
• Which framework are you using? It's possible for us to specialize the defaults a bit more for different PHP environments.

[Spirit55555]

@Spirit55555 I'm not familiar with the PHP ecosystem, unfortunately! So you'll have to walk me through this.

* My understanding is _some_ pre/post install scripts require access to the runtime environment, not just a build environment (possible database access, etc). Does this sound right to you?

In post. yes, it's possible.
But then I think it's better it fails, instead of now, where it silently does not run it.

Maybe add support for an env like COMPOSER_INSTALL_ARGS where --no-scripts could be added if needed?

* What workaround did you end up using in your app?

I added a railpack.json file with the following:

{
	"$schema": "https://schema.railpack.com",
	"steps": {
		"composer-run-scripts": {
			"inputs": [
				{
					"step": "build"
				}
			],
			"commands": [
				"composer run-script post-install-cmd"
			]
		}
	}
}

* Which framework are you using? It's possible for us to specialize the defaults a bit more for different PHP environments.

I do not use a framework and I unfortunately have no experience with development using Laravel.

[iloveitaly]

@Spirit55555 Thanks so much for the detail. I'll need to read up on how all of these PHP frameworks operate a bit more. The tests are failing here, so I can't merge this without understanding the different patterns and improving a generalized solution here.

[Spirit55555]

@iloveitaly The error looks like a file permission issue to me, but I will have to test some to be sure.

[Spirit55555]

@iloveitaly After a bit of testing, it seems like the issue is that Composer is run before the copy / /app command. Composer needs access to all the files, as it might run pre/post scripts in other PHP files.

[iloveitaly]

@Spirit55555 in what cases would an installation process require access to the entire app? Just not familiar with the PHP ecosystem, and in ruby/python/go/typescript (which I'm familiar with) packages generally don't need access to your application source code.

The reason we try to separate build from install steps is to enable layer caching to repeats builds are much faster (i.e. if the same dependencies are used, no need to redownload them).

[Spirit55555]

@iloveitaly From the documentation: https://getcomposer.org/doc/articles/scripts.md

A script, in Composer's terms, can either be a PHP callback (defined as a static method) or any command-line executable command. Scripts are useful for executing a package's custom code or package-specific commands during the Composer execution process.

There are plenty of examples here on GitHub: https://github.com/search?q=%22post-install-cmd%22&type=code

The default is to run the pre/post scripts, so I think there should be very good reasons not to do this.

If you want to download the dependencies early in the process, you could run composer install with --download-only and then run the actual install later, when all the files are available:
composer install --no-dev --download-only --no-interaction

And later:
composer install --no-dev --optimize-autoloader --no-interaction

[iloveitaly]

@Spirit55555 Super helpful. This all makes sense. I need to spend some time with it and think through what changes are breaking, etc. I'm going to be able to get to it this week, but I think I have all of the detail I need from you, which is great.

[glennjacobs]

I think the --no-dev addition in this PR is important.

[andp97]

Hi there,

as a PHP/Laravel developer I can confirm that running composer install without the --no-dev flag will install dev dependencies that are not required in production and are generally considered bad practice (for reference: https://stackoverflow.com/a/45735836).

For example, dependencies used in local environments for debugging (e.g. barryvdh/laravel-debugbar, laravel/telescope) are unnecessary and wasteful in production.

I think we should have the ability to choose which flags to pass during installation, such as --no-dev to exclude dev dependencies in production environments.

Adding --no-scripts will also break some dependencies that rely on Composer scripts, for example Filament.

In my case I've "fixed" the missing post-install script using a start-container.sh.

The solution proposed by @Spirit55555 to add a COMPOSER_INSTALL_ARGS env variable looks good to me. However, by default, if no flag is passed, it should produce a production build by passing --no-dev, in my opinion.

I've used Railpack with a fresh Laravel starter kit project and dev dependencies broke the build because they require a Node.js runtime in the PHP build step. This is expected in a local environment, but in a production-ready pod I don't think the Node.js binary should be present in the same PHP container.

I'll try to produce a PoC with some example if needed and make a PR to try this.

Best Regards.