Difference Between Require and Install VS Create-Project in Composer

Difference between require and install vs create-project in composer

require will add a dependency to the composer.json file and load it into the vendor directory as you have correctly noticed.

create-project on the other hand will clone the dependency, i.e. use the dependency as a template for a new project. Take a look at the repository behind laravel/laravel: https://github.com/laravel/laravel

What is the difference between require and require-dev sections in composer.json?

Different Environments

Typically, software will run in different environments:

• development
• testing
• staging
• production

Different Dependencies in Different Environments

The dependencies which are declared in the require section of composer.json are typically dependencies which are required for running an application or a package in

• staging
• production

environments, whereas the dependencies declared in the require-dev section are typically dependencies which are required in

• developing
• testing

environments.

For example, in addition to the packages used for actually running an application, packages might be needed for developing the software, such as:

• friendsofphp/php-cs-fixer (to detect and fix coding style issues)
• squizlabs/php_codesniffer (to detect and fix coding style issues)
• phpunit/phpunit (to drive the development using tests)
• etc.

Deployment

Now, in development and testing environments, you would typically run

$ composer install

to install both production and development dependencies.

However, in staging and production environments, you only want to install dependencies which are required for running the application, and as part of the deployment process, you would typically run

$ composer install --no-dev

to install only production dependencies.

Semantics

In other words, the sections

• require
• require-dev

indicate to composer which packages should be installed when you run

$ composer install

or

$ composer install --no-dev

That is all.

Note Development dependencies of packages your application or package depend on will never be installed

For reference, see:

• https://getcomposer.org/doc/04-schema.md#require
• https://getcomposer.org/doc/04-schema.md#require-dev

Differences between install via artisan and composer

The difference between both commands is that the composer command uses packagist to get the latest package from GitHub the first time or a cached version, while laravel new blog downloads a zip file from the Laravel server which has the latest version and uses that. Both commands run the so called 'after install' scripts, creating an environment file and setting the application key.

When you don't want a cached version but a new one using composer, run composer clear-cache first, to delete the local cache composer creates.

If you want to see the difference for yourself, compare the composer.json of the base Laravel project (https://www.github.com/laravel/laravel) and the NewCommand.php file in the src directory of the Laravel installer (https://www.github.com/laravel/installer)

Edit

After running both commands, the only difference I could really find was the order in which some things are done, but both generate a working system. Fun thing I noticed is that laravel new project comes with a yarn.lock file, but without a readme.md and composer composer create-project vice versa.

What's the difference between require and require-dev?

The require-dev packages are packages that aren't necessary for your project to work and shouldn't be included in the production version of your project.

Typically, these are packages such as phpunit/phpunit that you would only use during development.

What are the differences between composer update and composer install?

composer update

composer update will update your depencencies as they are specified in composer.json

For example, if you require this package as a dependency:

"mockery/mockery": "0.9.*",

and you have actually installed the 0.9.1 version of the package, running composer update will cause an upgrade of this package (for example to 0.9.2, if it's already been released)

in detail composer update will:

• Read composer.json
• Remove installed packages that are no more required in composer.json
• Check the availability of the latest versions of your required packages
• Install the latest versions of your packages
• Update composer.lock to store the installed packages version

composer install

composer install will not update anything; it will just install all the dependencies as specified in the composer.lock file

In detail:

• Check if composer.lock file exists (if not, it will run composer update and create it)
• Read composer.lock file
• Install the packages specified in the composer.lock file

When to install and when to update

• composer update is mostly used in the 'development phase', to upgrade our project packages according to what we have specified in the composer.json file,

• composer install is primarily used in the 'deploying phase' to install our application on a production server or on a testing environment, using the same dependencies stored in the composer.lock file created by composer update.

What is the difference between laravel create blog and composer create-project --prefer-dist laravel/laravel blog?

In order to run the command

laravel new blog

You need to have the laravel installer globally available.

So

composer global require "laravel/installer=~1.1"

Run the above command once and you will be ready to use the laravel new blog command for the rest of the life time. This method is fast and installs all dependencies.

Now for the second method:

composer create-project laravel/laravel {directory} "~5.1.0" --prefer-dist

You gotta be running this command everytime and update the dependencies to its latest one.

So overall, laravel new blog would be the fastest and most efficient approach since you have the laravel installer available globally.

You can read more here: https://laravel.com/docs/5.1/installation

Laravel Framework - Difference between creating a new project via laravel or composer?

composer create-project laravel/laravel project-name will do two extra things as far as I know. These are executed because of scripts in composer.json

1. cp .env.example .env
2. ./artisan key:generate

composer.json

Build with Composer

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:

1. composer install --no-dev - Prepare the vendor folder with the production dependencies and the autoloader.
2. 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).

---

Related Topics