public-mirrors
/
composer
mirror of https://github.com/composer/composer
1
0
Fork 0
Code

Remove fenced blocks in docs

pull/375/merge
Jordi Boggiano 2012-02-29 15:56:53 +01:00
parent 0e6cf61b67
commit 605fae42a6
7 changed files with 210 additions and 274 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
doc/00-intro.md
View File

@ -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';
```
require 'vendor/.composer/autoload.php';
That's all it takes to have a basic setup.

30
doc/01-basic-usage.md
View File

@ -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';
```
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 = new Monolog\Logger('name');
$log->pushHandler(new Monolog\Handler\StreamHandler('app.log', Logger::WARNING));
$log->addWarning('Foo');
```
$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__);
```
$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`,

24
doc/02-libraries.md
View File

@ -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,8 +116,7 @@ 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": {
"acme/hello-world": {
@ -133,8 +126,7 @@ We do this by adding a package repository specification to the blog's
"require": {
"acme/hello-world": "dev-master"
}
}
```
}
For more details on how package repositories work and what other types are
available, see [Repositories].

64
doc/04-schema.md
View File

@ -134,8 +134,7 @@ Each author object can have following properties:
An example:
```json
{
{
"authors": [
{
"name": "Nils Adermann",
@ -148,8 +147,7 @@ An example:
"homepage": "http://seld.be"
}
]
}
```
}
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,8 +251,7 @@ For more information on any of these, see [Repositories].
Example:
```json
{
{
"repositories": [
{
"type": "composer",
@ -291,8 +282,7 @@ Example:
}
}
]
}
```
}
> **Note:** Order is significant here. Repositories added later will take
precedence. This also means that custom repositories can override packages
@ -301,15 +291,13 @@ that exist on packagist.
You can also disable the packagist repository by setting `packagist` to
`false`.
```json
{
{
"repositories": [
{
"packagist": false
}
]
}
```
}
## config
@ -327,13 +315,11 @@ The following options are supported:
Example:
```json
{
{
"config": {
"bin-dir": "bin"
}
}
```
}
## scripts
@ -368,35 +354,31 @@ handle it.
Example:
```json
{
{
"scripts": {
"post-install-cmd": [
"Acme\\ScriptHandler::doSomething"
]
}
}
```
}
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;
namespace Acme;
use Composer\Script\Event;
use Composer\Script\Event;
class ScriptHandler
{
class ScriptHandler
{
static public function doSomething(Event $event)
{
$composer = $event->getComposer();
// 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();
```
$extra = $event->getComposer()->getPackage()->getExtra();
Optional.

30
doc/05-repositories.md
View File

@ -52,8 +52,7 @@ 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",
"description": "Package description",
@ -62,8 +61,7 @@ format is as follows:
"1.0.0": { @composer.json }
}
}
}
```
}
The `@composer.json` marker would be the contents of the `composer.json` from
that package version including as a minimum:
@ -74,16 +72,14 @@ that package version including as a minimum:
Here is a minimal package definition:
```json
{
{
"name": "smarty/smarty",
"version": "3.1.7",
"dist": {
"url": "http://www.smarty.net/files/Smarty-3.1.7.zip",
"type": "zip"
}
}
```
}
It may include any of the other fields specified in the [schema].
@ -111,8 +107,7 @@ point to your custom branch.
Example assuming you patched monolog to fix a bug in the `bugfix` branch:
```json
{
{
"repositories": [
{
"type": "vcs",
@ -122,8 +117,7 @@ Example assuming you patched monolog to fix a bug in the `bugfix` branch:
"require": {
"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,8 +148,7 @@ avoid conflicts.
Example using `pear2.php.net`:
```json
{
{
"repositories": [
{
"type": "pear",
@ -165,8 +158,7 @@ Example using `pear2.php.net`:
"require": {
"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,8 +179,7 @@ minimum required fields are `name`, `version`, and either of `dist` or
Here is an example for the smarty template engine:
```json
{
{
"repositories": [
{
"type": "package",
@ -210,8 +201,7 @@ Here is an example for the smarty template engine:
"require": {
"smarty/smarty": "3.1.*"
}
}
```
}
Typically you would leave the source part off, as you don't really need it.

18
doc/articles/scripts.md
View File

@ -34,24 +34,21 @@ functionality.
Script definition example:
```json
{
{
"scripts": {
"post-update-cmd": "MyVendor\\MyClass::postUpdate",
"post-package-install": ["MyVendor\\MyClass::postPackageInstall"]
}
}
```
}
Script listener example:
```php
<?php
<?php
namespace MyVendor;
namespace MyVendor;
class MyClass
{
class MyClass
{
public static function postUpdate($event)
{
// do stuff
@ -62,5 +59,4 @@ class MyClass
$installedPackage = $event->getOperation()->getPackage();
// do stuff
}
}
```
}

24
doc/articles/vendor-bins.md
View File

@ -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