Composer Library (Resource Pack)

Library (Resource Pack)

This chapter will show you how to install your library through Composer.

Each item is a package

As long as you composer.json file in the directory, the entire directory is a package. W hen you add a require a project, you are creating a package that depends on other libraries. The only difference between your project and the library is that your project is a named package.

In order for it to become an installable package, you need to give it a name. You can composer.json name

{
    "name": "acme/hello-world",
    "require": {
        "monolog/monolog": "1.0.*"
    }
}

In this case, the name acme/hello-world where acme the name of the vendor. The name of the vendor must be filled in.

Note: If you don't know what to use as the vendor's name, using the userna name on your github is usually a good choice. Although the package name is case insenseconcable, it is customary to use lowercase letters and to use hyphens as the separation of words.

Platform packages

Composer treats packages that are already installed on the system but are not installed by Composer as virtual platform packages. This includes PHP itself, PHP extensions, and some system libraries.

• php a user's PHP version requirements, which you can restrict. F or >=5.4.0 If you need a 64-bit version of php-64bit to limit it.

• hhvm the version of the HHVM (i.e. HipHop Virtual Machine) running environment and allows you to set a version limit, for example, ''gt;'2.3.3'.'

• ext-<name> you specify the PHP extensions you need, including core extensions. U sually PHP-extended versions can be inconsistent, and it's a good idea * their versions to . An example of a PHP extension package: The package name can be written ext-gd

• lib-<name> to restrict the version of the PHP library.
  The following are the names curl iconv icu libxml openssl pcre uuid xsl

You can use composer show --platform command to get a list of available platform packages.

Indicates the version

You need some way to indicate the version of the package you developed, and when you publish your own package on Packagist, it can infer the version of the package from the information of VCS (git, svn, hg), so you don't have to manually indicate the version number, and it's not recommended. Check the tags and branches to see how the version number is extracted.

If you want to create it manually and really specify it explicitly, you just need to add version field:

{
    "version": "1.0.0"
}

Note: You should try to avoid setting the version number manually because the value of the label must match the label name.

Label

For each label that looks like a version number, a version of the package is created accordingly. I t should be in the form of 'X.Y.Z' or 'vX.Y.Z', and the suffixes -patch -alpha -beta -RC are optional. You can also keep up with a number after the suffix.

Here are a few examples of valid label names:

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

• v2.0.4-p1

  Note: Even if your label has a prefix v v will be require because it is not allowed when a constraint on a version of v required (for V1.0.0 1.0.0

Branch

For each branch, a development version of the package is created accordingly. I f the branch name looks like a version number, a package version number that looks like the branch name {分支名}-dev is created. F or example, 2.0 produce a version of the 2.0.x-dev package .x is for technical reasons to 2.0.x is also allowed, and it is 2.0.x-dev I f the branch name doesn't look like a version number, it creates a version number in the form of dev-{分支名} name. Master, for example, produces dev-master master

Here are some examples of version branch names:

• 1.x
• 1.0 (equals 1.0.x)

• 1.1.x

  Note: When you install a new version, it is automatically source from its source. See the install command for details.

Alias

It represents an alias for a package version. For example, you dev-master 1.0.x-dev so that you can get the dev-master version of the package by 1.0.x-dev dev-master

See the alias for details.

Lock the file

If you prefer, you can submit the composer.lock project. H e will help your team always test against the same dependent version. At any time, this lock file only affects your project.

If you don't want to submit a lock file and you're using Git, add it .gitignore file.

Released to VCS (Online Version Control System)

Once you have a library composer.json stored in an online version control system (ex: Git), your library can be installed by Composer. In this example, we acme/hello-world library in the github.com/username/hello-world GitHub. github.com/username/hello-world

Now test this acme/hello-world and we'll create a new project locally. W e named acme/blog T his blog will rely acme/hello-world which in turn will rely monolog/monolog We can create a new blog folder blog to do it, and we need to include composer.json file:

{
    "name": "acme/blog",
    "require": {
        "acme/hello-world": "dev-master"
    }
}

Name is not name in this example because we don't want to publish it as a library. Add a composer.json file here.

Now we need to tell our app where to hello-world dependencies. To do this, we need to add the repositories source statement in composer.json

{
    "name": "acme/blog",
    "repositories": [
        {
            "type": "vcs",
            "url": "https://github.com/username/hello-world"
        }
    ],
    "require": {
        "acme/hello-world": "dev-master"
    }
}

For more information about how the source of the package works and what other types are available, check out the Library.

That's all. You can now install your install package using Composer's install command!

Conclusion: Any GIT SVN HG repository with composer.json can require your project by specifying "package source" and "declaration dependency" through the require field.

Publish to packagist

Okay, you can publish your package now, but you won't want your users to specify the source of the package so tediously every time.

Another thing you may have noticed is that we monolog/monolog H ow does it work? The answer is packagist.

Packagist is Composer's primary repository of package information, which is enabled by default. A ny package published on packagist can be used directly by Composer. Just as monolog is published on packagist, we can use it directly without specifying any additional source information.

If we want to share our hello-world world, we'd better publish it on packagist. It's easy to do that.

All you have to do is click on that big "Submit Package" button and register. T hen submit the source address of your library, and the packagist starts crawling. Once completed, your package will be available to anyone.