Remove fenced blocks in docs
Jordi Boggiano
parent
0e6cf61b67
commit
605fae42a6
|
|
@ -26,13 +26,11 @@ You decide to use [monolog](https://github.com/Seldaek/monolog). In order to
|
|||
add it to your project, all you need to do is create a `composer.json` file
|
||||
which describes the project's dependencies.
|
||||
|
||||
```json
|
||||
{
|
||||
"require": {
|
||||
"monolog/monolog": "1.0.*"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
We are simply stating that our project requires the `monolog/monolog` package,
|
||||
any version beginning with `1.0`.
|
||||
|
|
@ -58,8 +56,6 @@ This will download monolog and dump it into `vendor/monolog/monolog`.
|
|||
After this you can just add the following line to your bootstrap code to get
|
||||
autoloading:
|
||||
|
||||
```php
|
||||
require 'vendor/.composer/autoload.php';
|
||||
```
|
||||
|
||||
That's all it takes to have a basic setup.
|
||||
|
|
|
|||
|
|
@ -42,13 +42,11 @@ The first (and often only) thing you specify in `composer.json` is the
|
|||
`require` key. You're simply telling composer which packages your project
|
||||
depends on.
|
||||
|
||||
```json
|
||||
{
|
||||
"require": {
|
||||
"monolog/monolog": "1.0.*"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
As you can see, `require` takes an object that maps package names to versions.
|
||||
|
||||
|
|
@ -141,32 +139,26 @@ naming standard, composer generates a
|
|||
`vendor/.composer/autoload.php` file for autoloading. You can simply include
|
||||
this file and you will get autoloading for free.
|
||||
|
||||
```php
|
||||
require 'vendor/.composer/autoload.php';
|
||||
```
|
||||
|
||||
This makes it really easy to use third party code, because you only
|
||||
have to add one line to `composer.json` and run `install`. For monolog, it
|
||||
means that we can just start using classes from it, and they will be
|
||||
autoloaded.
|
||||
|
||||
```php
|
||||
$log = new Monolog\Logger('name');
|
||||
$log->pushHandler(new Monolog\Handler\StreamHandler('app.log', Logger::WARNING));
|
||||
|
||||
$log->addWarning('Foo');
|
||||
```
|
||||
|
||||
You can even add your own code to the autoloader by adding an `autoload` field
|
||||
to `composer.json`.
|
||||
|
||||
```json
|
||||
{
|
||||
"autoload": {
|
||||
"psr-0": {"Acme": "src/"}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
This is a mapping from namespaces to directories. The `src` directory would be
|
||||
in your project root. An example filename would be `src/Acme/Foo.php`
|
||||
|
|
@ -179,10 +171,8 @@ Including that file will also return the autoloader instance, so you can store
|
|||
the return value of the include call in a variable and add more namespaces.
|
||||
This can be useful for autoloading classes in a test suite, for example.
|
||||
|
||||
```php
|
||||
$loader = require 'vendor/.composer/autoload.php';
|
||||
$loader->add('Acme\Test', __DIR__);
|
||||
```
|
||||
|
||||
> **Note:** Composer provides its own autoloader. If you don't want to use
|
||||
that one, you can just include `vendor/.composer/autoload_namespaces.php`,
|
||||
|
|
|
|||
|
|
@ -12,14 +12,12 @@ libraries is that your project is a package without a name.
|
|||
In order to make that package installable you need to give it a name. You do
|
||||
this by adding a `name` to `composer.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "acme/hello-world",
|
||||
"require": {
|
||||
"monolog/monolog": "1.0.*"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
In this case the project name is `acme/hello-world`, where `acme` is the
|
||||
vendor name. Supplying a vendor name is mandatory.
|
||||
|
|
@ -36,11 +34,9 @@ the repository is able to infer the version from elsewhere.
|
|||
|
||||
If you do want to specify it explicitly, you can just add a `version` field:
|
||||
|
||||
```json
|
||||
{
|
||||
"version": "1.0.0"
|
||||
}
|
||||
```
|
||||
|
||||
However if you are using git, svn or hg, you don't have to specify it.
|
||||
Composer will detect versions as follows:
|
||||
|
|
@ -105,14 +101,12 @@ project locally. We will call it `acme/blog`. This blog will depend on `acme
|
|||
this by creating a new `blog` directory somewhere, containing a
|
||||
`composer.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "acme/blog",
|
||||
"require": {
|
||||
"acme/hello-world": "dev-master"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
The name is not needed in this case, since we don't want to publish the blog
|
||||
as a library. It is added here to clarify which `composer.json` is being
|
||||
|
|
@ -122,7 +116,6 @@ Now we need to tell the blog app where to find the `hello-world` dependency.
|
|||
We do this by adding a package repository specification to the blog's
|
||||
`composer.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "acme/blog",
|
||||
"repositories": {
|
||||
|
|
@ -134,7 +127,6 @@ We do this by adding a package repository specification to the blog's
|
|||
"acme/hello-world": "dev-master"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
For more details on how package repositories work and what other types are
|
||||
available, see [Repositories].
|
||||
|
|
|
|||
|
|
@ -134,7 +134,6 @@ Each author object can have following properties:
|
|||
|
||||
An example:
|
||||
|
||||
```json
|
||||
{
|
||||
"authors": [
|
||||
{
|
||||
|
|
@ -149,7 +148,6 @@ An example:
|
|||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Optional, but highly recommended.
|
||||
|
||||
|
|
@ -173,13 +171,11 @@ Each of these takes an object which maps package names to version constraints.
|
|||
|
||||
Example:
|
||||
|
||||
```json
|
||||
{
|
||||
"require": {
|
||||
"monolog/monolog": "1.0.*"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Optional.
|
||||
|
||||
|
|
@ -194,13 +190,11 @@ package root.
|
|||
|
||||
Example:
|
||||
|
||||
```json
|
||||
{
|
||||
"autoload": {
|
||||
"psr-0": { "Monolog": "src/" }
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Optional, but it is highly recommended that you follow PSR-0 and use this.
|
||||
|
||||
|
|
@ -220,14 +214,12 @@ it from `vendor/symfony/yaml`.
|
|||
|
||||
To do that, `autoload` and `target-dir` are defined as follows:
|
||||
|
||||
```json
|
||||
{
|
||||
"autoload": {
|
||||
"psr-0": { "Symfony\\Component\\Yaml": "" }
|
||||
},
|
||||
"target-dir": "Symfony/Component/Yaml"
|
||||
}
|
||||
```
|
||||
|
||||
Optional.
|
||||
|
||||
|
|
@ -259,7 +251,6 @@ For more information on any of these, see [Repositories].
|
|||
|
||||
Example:
|
||||
|
||||
```json
|
||||
{
|
||||
"repositories": [
|
||||
{
|
||||
|
|
@ -292,7 +283,6 @@ Example:
|
|||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
> **Note:** Order is significant here. Repositories added later will take
|
||||
precedence. This also means that custom repositories can override packages
|
||||
|
|
@ -301,7 +291,6 @@ that exist on packagist.
|
|||
You can also disable the packagist repository by setting `packagist` to
|
||||
`false`.
|
||||
|
||||
```json
|
||||
{
|
||||
"repositories": [
|
||||
{
|
||||
|
|
@ -309,7 +298,6 @@ You can also disable the packagist repository by setting `packagist` to
|
|||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## config
|
||||
|
||||
|
|
@ -327,13 +315,11 @@ The following options are supported:
|
|||
|
||||
Example:
|
||||
|
||||
```json
|
||||
{
|
||||
"config": {
|
||||
"bin-dir": "bin"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## scripts
|
||||
|
||||
|
|
@ -368,7 +354,6 @@ handle it.
|
|||
|
||||
Example:
|
||||
|
||||
```json
|
||||
{
|
||||
"scripts": {
|
||||
"post-install-cmd": [
|
||||
|
|
@ -376,13 +361,11 @@ Example:
|
|||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
The event handler receives a `Composer\Script\Event` object as an argument,
|
||||
which gives you access to the `Composer\Composer` instance through the
|
||||
`getComposer` method.
|
||||
|
||||
```php
|
||||
namespace Acme;
|
||||
|
||||
use Composer\Script\Event;
|
||||
|
|
@ -396,7 +379,6 @@ class ScriptHandler
|
|||
// custom logic
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## extra
|
||||
|
||||
|
|
@ -405,9 +387,7 @@ Arbitrary extra data for consumption by `scripts`.
|
|||
This can be virtually anything. To access it from within a script event
|
||||
handler, you can do:
|
||||
|
||||
```php
|
||||
$extra = $event->getComposer()->getPackage()->getExtra();
|
||||
```
|
||||
|
||||
Optional.
|
||||
|
||||
|
|
|
|||
|
|
@ -52,7 +52,6 @@ The main repository type is the `composer` repository. It uses a single
|
|||
`packages.json` file that contains all of the package metadata. The JSON
|
||||
format is as follows:
|
||||
|
||||
```json
|
||||
{
|
||||
"vendor/packageName": {
|
||||
"name": "vendor/packageName",
|
||||
|
|
@ -63,7 +62,6 @@ format is as follows:
|
|||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
The `@composer.json` marker would be the contents of the `composer.json` from
|
||||
that package version including as a minimum:
|
||||
|
|
@ -74,7 +72,6 @@ that package version including as a minimum:
|
|||
|
||||
Here is a minimal package definition:
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "smarty/smarty",
|
||||
"version": "3.1.7",
|
||||
|
|
@ -83,7 +80,6 @@ Here is a minimal package definition:
|
|||
"type": "zip"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
It may include any of the other fields specified in the [schema].
|
||||
|
||||
|
|
@ -111,7 +107,6 @@ point to your custom branch.
|
|||
|
||||
Example assuming you patched monolog to fix a bug in the `bugfix` branch:
|
||||
|
||||
```json
|
||||
{
|
||||
"repositories": [
|
||||
{
|
||||
|
|
@ -123,7 +118,6 @@ Example assuming you patched monolog to fix a bug in the `bugfix` branch:
|
|||
"monolog/monolog": "dev-bugfix"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
When you run `php composer.phar update`, you should get your modified version
|
||||
of `monolog/monolog` instead of the one from packagist.
|
||||
|
|
@ -154,7 +148,6 @@ avoid conflicts.
|
|||
|
||||
Example using `pear2.php.net`:
|
||||
|
||||
```json
|
||||
{
|
||||
"repositories": [
|
||||
{
|
||||
|
|
@ -166,7 +159,6 @@ Example using `pear2.php.net`:
|
|||
"pear-pear2/PEAR2_HTTP_Request": "*"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
In this case the short name of the channel is `pear2`, so the
|
||||
`PEAR2_HTTP_Request` package name becomes `pear-pear2/PEAR2_HTTP_Request`.
|
||||
|
|
@ -187,7 +179,6 @@ minimum required fields are `name`, `version`, and either of `dist` or
|
|||
|
||||
Here is an example for the smarty template engine:
|
||||
|
||||
```json
|
||||
{
|
||||
"repositories": [
|
||||
{
|
||||
|
|
@ -211,7 +202,6 @@ Here is an example for the smarty template engine:
|
|||
"smarty/smarty": "3.1.*"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Typically you would leave the source part off, as you don't really need it.
|
||||
|
||||
|
|
|
|||
|
|
@ -34,18 +34,15 @@ functionality.
|
|||
|
||||
Script definition example:
|
||||
|
||||
```json
|
||||
{
|
||||
"scripts": {
|
||||
"post-update-cmd": "MyVendor\\MyClass::postUpdate",
|
||||
"post-package-install": ["MyVendor\\MyClass::postPackageInstall"]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Script listener example:
|
||||
|
||||
```php
|
||||
<?php
|
||||
|
||||
namespace MyVendor;
|
||||
|
|
@ -63,4 +60,3 @@ class MyClass
|
|||
// do stuff
|
||||
}
|
||||
}
|
||||
```
|
||||
|
|
|
|||
|
|
@ -16,11 +16,9 @@ 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.
|
||||
|
||||
```json
|
||||
{
|
||||
"bin": ["bin/my-script", "bin/my-other-script"]
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
## What does defining a bin in composer.json do?
|
||||
|
|
@ -44,26 +42,22 @@ symlink is created from each dependency's bins to `vendor/bin`.
|
|||
|
||||
Say package `my-vendor/project-a` has bins setup like this:
|
||||
|
||||
```json
|
||||
{
|
||||
"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:
|
||||
|
||||
```json
|
||||
{
|
||||
"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`.
|
||||
|
|
@ -97,13 +91,11 @@ Yes, there are two ways that an alternate vendor bin location can be specified.
|
|||
|
||||
An example of the former looks like this:
|
||||
|
||||
```json
|
||||
{
|
||||
"config": {
|
||||
"bin-dir": "scripts"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Running `composer install` for this `composer.json` will result in
|
||||
all of the vendor bins being installed in `scripts/` instead of
|
||||
|
|
|
|||
Loading…
Reference in New Issue