Detailed structure Composer

Composer structure

   Root Package (root package)

     The root of the package is the package defined by the composer.json in the root directory of your project. Mainly to define the dependencies of your project by composer.json.
     Some fields can only be used in the root directory of the package, such as config field, only the root of the package can define your own configuration. The config field dependencies are ignored. So config field is the root-only.
     If you cloned one of dependencies and work on it, then this package is the root of the package. composer.json still the same, but different contexts.
     (Note: a package is not a root package, depending on the context.)

   composer.json the individual attributes (fields)

• name . Package name. By the supplier (vendor) name, and project name, separated by /. == released when the package need to fill ==.
• description a brief description of the package, usually the length of a line. == released when the package need to fill ==.
• version version of the package. Format must be XYZ, selective suffix: -dev, -alphaN, -betaN, -RCN .
• type type of package, by default library. Packet Type == == logic for custom installation. If your package needs some special logic, you can define a custom type. It can be a symfony-bundle type, or wordpress-plugin, or typo3-module. These types will be used by a particular item, they will provide the installer to install these types of packages.

   Composer supports three types:

• library: the default value. It copies the file to the vendor directory.
• project: it indicates that this is a project, not the library. Such as Symfony Standard Edition this application.
• metapackage: a package containing dependent empty, can trigger the installation, but does not contain the file, do not write anything to the file system.
• composer-install: providing an installation package to other types of customized package.
• keywords associated with a package of keywords array. For searching and filtering package. Optional.

   homepage

• The project website URL.
• Optional.

   time

• Release time.
• It must be YYYY-MM-DD or YYYY-MM-DD HH: MM: SS format.
• Optional.

   license

• License package.
• It may be a string or array of strings.
• Optional, but highly recommended plus.

   The authors of the package. Is an array of objects. Each author object has these attributes:

name: the name of the 
 email: Author mailbox 
 homepage: author's website the URL of 
 Role: Authors role in the project (such as: developer or translator)

   support a variety of information about how to obtain the support of the project. These attributes include:

email: mail for support 
 issues: URL issue tracking 
 forum: URL Forum 
 wiki: Wiki's URL 
 irc: IRC channel 
 source: view or download the source code of the URL 
 is optional.

   Package links

     Dependency mapping table package, the package name mapping version constraints. Such as:

 {
    "require": {
        "monolog/monolog": "1.0.*"
    }
 }

   List require packages package depends.

     Unless these dependencies already exist, otherwise the package will not be installed.

   require-dev (root-only) are listed in the development of this packet (or running test, etc.) of the dependent packages.

     When using the install command, only to bring "-dev" parameter to install dev package. When using the update command, to bring "-no-dev" not updated.

   conflict will be listed in the package and what package conflicts.

     They will not be allowed and installed with your package. If the constraint version, only for a specific version.

   replace lists which packages should be replaced by this package.

   This package provide a list of recommended package.

     This is most useful for the public interface, a packet logger can rely on a virtual package, and achieve logger library interface can provide into the field.

   suggest some suggestions to make this package work better or enhanced package list.

     This information is only given when the package installation is complete, suggesting that the user can add more packages, although not required to be installed.
     The format is, the package name mapping text, such as:

 {
    "suggest": {
        "monolog/monolog": "Allows more advanced logging of the application flow"
    }
 }

   autoload

     PHP autoloader to provide automatic load map.
     Currently supported are: PSR-0 automatically load specification, classmap generator, as well as files.
     PSR-0 is more preferred, because of its excellent expandability (for adding a new class, does not need to regenerate the autoloader).
     

    (1) PSR-0
     in the psr-0 bond name, a namespace is defined to map the path, relative to the root package. Note that this also does not support namespace PEAR-style of style.
     Note that the namespace declaration to \ the end, make sure the autoloader correct response.
     PSR-0 reference may be generated at the time of installation or update files See:
     Vendor / Composer / autoload_namespaces.php
     example :

 {
    "autoload": {
        "psr-0": {
            "Monolog\\": "src/",
            "Vendor\\Namespace\\": "src/",
            "Vendor_Namespace_": "src/"
        }
    }
 }

     If you need to find the same namespace prefix in multiple directories, you can use an array, such as:

 {
    "autoload": {
        "psr-0": { "Monolog\\": ["src/", "lib/"] }
    }
 }

     PSR-0 style is not limited to what is loaded namespace declaration, and can also be used like this level. When the library is only a space in the class named in a global, this way you can spend. For example, you have a PHP source file in the root directory of the project, you can declare:

 {
    "autoload": {
        "psr-0": { "UniqueGlobalClass": "" }
    }

 }

     If you have full use namespaces organize the next directory, you can use an empty prefix:

 {
    "autoload": {
        "psr-0": { "": "src/" }
    }
 }

   （2）Classmap

     classmap reference may be generated at the time of installation or update files See:
     Vendor / Composer / autoload_classmap.php
     class mapping table and .inc .php all files in the specified directory, or by scanning a document generated.
     You can give any library does not support the PSR-0 is automatically loaded with the classmap generator. As long as the configuration directory or file specified class where you can:

  {
    "autoload": {
        "classmap": ["src/", "lib/", "Something.php"]
    }
  }

   （3）files

     You need to determine if certain files are loaded at any request, you can use the files automatically loading mechanism. When the package is particularly useful for those in some PHP functions but does not automatically load. E.g:

 {
    "autoload": {
        "files": ["src/MyLibrary/functions.php"]
    }
 }

   include-path

     (It will be deprecated its function autoload in place by the fact that set include_path, optional)

   target-dir

     Specify the installation destination path.

     If the root directory of the package is in the namespace automatically load is not correct, so the only target-dir to solve this problem.

     Symfony is an example. It consists of many components packets. Yaml component is in

     Symfony \ Component \ Yaml
     under namespace, its root directory is Yaml directory. Let the automatic loading work, we want to make sure that it is not installed in the
     Vendor / symfony / YAML
     , but in the
     Vendor / symfony / YAML / Symfony / the Component / YAML
     , this automatic loader to load it from the vendor / symfony / yaml.
     So as to define the target-dir:

 {
    "autoload": {
        "psr-0": { "Symfony\\Component\\Yaml\\": "" }
    },
    "target-dir": "Symfony/Component/Yaml"
 }

   minimum-stability（root-only）

     The filtering package defines how stability. The default is stable, if you trust a dev package, you need to specify.

   prefer-stable（root-only）

     If enabled, Composer will choose the former in stable and unstable packages package.

   repositories（root-only）

     Warehouse addresses a custom package.

     The default, Composer only Packagist warehouse. You can get packages from anywhere by specifying the address of the warehouse.

     Warehouse is not recursive. You can add them to the Lord in composer.json. Warehouse defined package composer.json file dependencies are ignored.

     Type supports warehouse are:

• Composer
  Composer warehouse provides packages.json files over a network, which contains a list of composer.json object, there are additional dist or source information. packages.json file is loaded by PHP stream.
• vcs
  version control system repository, such as: git, svn, hg.
• pear
  through it, you can import any pear warehouse to your project.
• package
  if you rely on a composer does not support the project, you can define a package type of warehouse, then composer.json object directly written.

      Complete example:

 {
    "repositories": [
        {
            "type": "composer",
            "url": "http://packages.example.com"
        },
        {
            "type": "composer",
            "url": "https://packages.example.com",
            "options": {
                "ssl": {
                    "verify_peer": "true"
                }
            }
        },
        {
            "type": "vcs",
            "url": "https://github.com/Seldaek/monolog"
        },
        {
            "type": "pear",
            "url": "http://pear2.php.net"
        },
        {
            "type": "package",
            "package": {
                "name": "smarty/smarty",
                "version": "3.1.7",
                "dist": {
                    "url": "http://www.smarty.net/files/Smarty-3.1.7.zip",
                    "type": "zip"
                },
                "source": {
                    "url": "http://smarty-php.googlecode.com/svn/",
                    "type": "svn",
                    "reference": "tags/Smarty_3_1_7/distribution/"
                }
            }
        }
    ]
 }

   config（root-only）

     For some configuration items:

  process-timeout: the default 300 Miao, Composer process execution timeout; 
  use -include-path: the default false , if it is to true , Composer autoloader to PHP's include_path will find; 
  of Preferred - install : default auto, setting Composer installation way; 
  github - protocols: default [ "git", "https" ], set the github communication protocol; 
  github - oauth: set oauth; 
  vendor - dir : default vendor, you can be replaced by another; 
  bin - dir : default vendor / bin, if projects are binary files, links to this; 
  cache - dir : default $ home / cache generated when the cache, store Composer run; 
  cache -files- dir: The default cache- $ dir / Files, storage package zip file; 
  Cache -repo- dir : default cache- $ dir / repo, storage warehouse metadata; 
  Cache -vcs- dir : default cache- $ dir / vcs, storage vcs cloning; 
  cache -files- ttl: default six months, the cache expiration time; 
  cache -files- MAXSIZE: default 300M; 
  the notify -NO- install : default to true , the installation package from the warehouse will have a notification can be switched off; 
  discard -changes: default false, how to handle the dirty update;

• scripts (root-only) Composer allows you to install hook scripts during the installation process, the hook is event-based;
• extra for additional data scripts consumption;
• bin specify which files must be treated as a binary file;
• archive
  settings Create option package, exclude property which can be set to exclude, for example:

 {
    "archive": {
        "exclude": ["/foo/bar", "baz", "/*.test", "!/foo/bar/baz"]
    }
 }