bin and vendor/bin

What is a bin?

Any runnable code that a Composer package would like to pass along to a user who installs the package should be listed as a bin.

If a package contains other runnable code that is not needed by the user (like build or compile scripts) that code need not be listed as a bin.

How is it defined?

It is defined by adding the bin key to a project's composer.json. It is specified as an array of files so multiple bins can be added for any given project.

{
    "bin": ["bin/my-script", "bin/my-other-script"]
}

What does defining a bin in composer.json do?

It instructs Composer to install the package's bins to vendor/bin for any project that depends on that project.

This is a convenient way to expose useful runnable code that would otherwise be hidden deep in the vendor/ directory.

What happens when Composer is run on a composer.json that defines bins?

For the bins that a package defines directly, nothing happens.

What happens when Composer is run on a composer.json that has dependencies with bins listed?

Composer looks for the bins defined in all of the dependencies. A symlink is created from each dependency's bins to vendor/bin.

Say package my-vendor/project-a has bins setup like this:

{
    "name": "my-vendor/project-a",
    "bin": ["bin/project-a-bin"]
}

Running composer install for this composer.json will not do anything with bin/project-a-bin.

Say project my-vendor/project-b has requirements setup like this:

{
    "name": "my-vendor/project-b",
    "requires": {
        "my-vendor/project-a": "*"
    }
}

Running composer install for this composer.json will look at all of project-b's dependencies and install them to vendor/bin.

In this case, Composer will create a symlink from vendor/my-vendor/project-a/bin/project-a-bin to vendor/bin/project-a-bin.

1.9 KiB Raw Blame History