Be consistent with composer scripts in CI

Keep it simple and save yourself some trouble

Joel Clermont
Joel Clermont

Composer scripts are a very handy way to define commands that you frequently use. For example, we have composer scripts to run tests or check coding style or update the IDE helper files.

But in that same scripts block of your composer.json file you can define actions that should be run when built-in Composer events are fired, like post-create-project-cmd and post-root-package-install.

Even though both of these things appear in the same scripts block, they're invoked in different ways.

For example, if you want to manually run the post-create-project-cmd script, you would need to call composer run post-create-project-cmd. If you don't specify run, you'll get the error: Command "post-create-project-cmd" is not defined.

But if you want to run one of the scripts you defined, like our ide-helper-update script, you can simply call composer ide-helper-update. Notice that specifying run is not required. You can specify it if you want, but you don't need to.

Any time there are two subtly different ways of doing something like this, I like to standardize on one to avoid confusion. So in this case, we always specify composer run, even for the scripts that don't need it. This way, we never have to think about it, and our CI commands are uniform.

Here to help,


P.S. Laravel form requests are another area where we've defined some repeatable, consistent ways of defining our validation logic. Check it out!

Toss a coin in the jar if you found this helpful.
Want a tip like this in your inbox every weekday? Sign up below 👇🏼

Level up your Laravel skills!

Each 2-minute email has real-world advice you can use.