Build with Composer - composer-php

Question

In a life cycle of a php project we have
install: composer install
publish: composer push
But, what would be the command to build a php project with composer?

Answer 1

what would be the command to build a php project with composer?
Simply speaking, you build the PHP project. Composer is a utility you can use to manage a PHP projects dependencies. Additionally you can also use it to define your PHP project.
How you build the PHP project is entirely up to you. This is normally dependent of what kind of PHP project that is and how you organize it.
To give an example: Lets consider your PHP project just is the project directory with the composer.json at its root with all the other sub-directories and files.
Composer operates within that directory. So when you want to create a build artifact of that project you do the following:
composer install --no-dev - Prepare the vendor folder with the production dependencies and the autoloader.
composer archive - Create the build artifact.
As you will do this quite often and over and over again you could add a Composer Script named build or similar to put things together:
{
"scripts": {
"build": [
"#composer --no-plugins --no-interaction install --no-scripts --no-dev",
"#composer --no-plugins --no-interaction archive"
]
},
"scripts-descriptions": {
"build": "Build project artifact."
}
}
You can then run:
$ composer build
...
Composer will then output the file-name. By default it should be a .tar file (tarfile, tarball), you can inspect it on the commandline with the tar utility (here gnutar):
$ tar -tvf "$(composer show -sN | sed 's|/|-|')"*.tar | less
And that would be the example. Whatever composer push is, I don't know. It is likely that you have it somewhere in your Composer configuration. So I can't comment on it.
To extend a bit on the given example: I manage most (if not even all) of my PHP projects with Composer. However this is not the full truth. I actually version control them with Git. Looking from a birds perspective, the Git utility is way more leading than the Composer utility. That is for example, that I want to be able to build a specific git revision.
Now Composer is not that bad with Git. It recognizes if the project exists and in case of the composer archive example, it even puts the git revision hash into the file name of the build artifact.
However Composer operates in-tree. That is the place where the development happens as well, so this can easily clash (you don't want the build to remove the development dependencies while you're running tests as well - or afterwards). And even Composer recognizes that the project is managed by Git, it is otherwise a bit dumb as Composer is merely concerned about the dependencies and knows very little about the project itself - it can't just guess how you manage the overall project.
So what then commonly happens is that you still use Composer during the build but you have a dedicated build process and runner that knows the ins and outs of the project and its build.
$ make
is such a runner. Works with a Makefile in the project, e.g.
$ make deploy
knows when it needs to build again. And speaking of PHP projects: It certainly can just rsync to remotes and run smoke-tests to mark the deployment as green (use old, dumb tech and keep it simple).