Skip to content

Instantly share code, notes, and snippets.

@hungtrinh
Forked from xeoncross/composer.md
Created May 21, 2020 14:56
Show Gist options
  • Save hungtrinh/df4c048f9de5b57127013b1afab67ccd to your computer and use it in GitHub Desktop.
Save hungtrinh/df4c048f9de5b57127013b1afab67ccd to your computer and use it in GitHub Desktop.
How composer actually works

Composer

the missing quick-start guide

We will assume we have a package/project called https://github.com/foo/bar

Most redistributable packages are hosted on a version control website such as Github or Bitbucket. Version control repositories often have a tagging system where we can define stable versions of our application. For example with git we can use the command:

git tag -a 1.0.0 -m 'First version.'

With this we have created version 1.0.0 of our application. This is a stable release which people can depend on. If we wanted to include "foo/bar" then we could create a composer.json and specify the tagged release we wanted:

{
	"require" : {
		"foo/bar": "1.0.0"
	}
}

If I wanted to include the most recent version of a certain release I could use a wildcard. For example, if I had 1.0.0, 1.0.1 and 1.0.2 all tagged then composer would load release 1.0.2 if I used the following composer.json:

{
	"require" : {
		"foo/bar": "1.0.*"
	}
}

We could also use the greater-than (>) and less-than (<) operators to specify tagged releases.

{
	"require" : {
		"foo/bar": ">1.0"
	}
}

Tags *

For every tag that looks like a version, a package version of that tag will be created. It should match 'X.Y.Z' or 'vX.Y.Z', with an optional suffix of -patch, -alpha, -beta or -RC. The suffixes can also be followed by a number.

Here are a few examples of valid tag names:

1.0.0
v1.0.0
1.10.5-RC1
v4.4.4beta2
v2.0.0-alpha
v2.0.4-p1

Branches

If the branch name looks like a version, the version will be {branchname}-dev. If the branch does not look like a version, it will be dev-{branchname}. master results in a dev-master version.

Here are some examples of version branch names and their composer equivalents.

master = dev-master
1.x = 1.x-dev
2.0 = 2.0.x-dev

If you want to checkout a branch instead of a tagged release, then you need to prefix it with dev-.

{
	"require" : {
		"foo/bar": "dev-master"
	}
}

These development version constraints will not work unless you have a correct minimum stability setting for your package. By default composer uses the stable minimum compatibility flag, which will restrict its dependency versions to stable, tagged releases.

If you would like to override this option, simply change the the minimum-stability configuration option within your composer.json file.

{
	"require" : {
		"foo/bar": "dev-master"
	},
	"minimum-stability": "dev"
}

Custom Repositories and Forks *

If you fork a project on github (or use your own VCS) then you will need to add instructions to composer to tell it where to find your package.

{
	"repositories": [
		{
			"type": "vcs",
			"url": "https://github.com/foo2/bar"
		}
	],
	"require" : {
		"foo/bar": "1.0.*"
	},
}

Credits

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment