Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

Remove fenced blocks in docs

  • Loading branch information...
commit 605fae42a694e0e36506e177b5e4d0efad734f65 1 parent 0e6cf61
@Seldaek Seldaek authored
View
14 doc/00-intro.md
@@ -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.*"
+ {
+ "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.
View
38 doc/01-basic-usage.md
@@ -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.*"
+ {
+ "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/"}
+ {
+ "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`,
View
52 doc/02-libraries.md
@@ -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.*"
+ {
+ "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"
-}
-```
+ {
+ "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"
+ {
+ "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,19 +116,17 @@ 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": {
- "vcs": { "url": "https://github.com/composer/hello-world" }
+ {
+ "name": "acme/blog",
+ "repositories": {
+ "acme/hello-world": {
+ "vcs": { "url": "https://github.com/composer/hello-world" }
+ }
+ },
+ "require": {
+ "acme/hello-world": "dev-master"
}
- },
- "require": {
- "acme/hello-world": "dev-master"
}
-}
-```
For more details on how package repositories work and what other types are
available, see [Repositories].
View
188 doc/04-schema.md
@@ -134,22 +134,20 @@ Each author object can have following properties:
An example:
-```json
-{
- "authors": [
- {
- "name": "Nils Adermann",
- "email": "naderman@naderman.de",
- "homepage": "http://www.naderman.de"
- },
- {
- "name": "Jordi Boggiano",
- "email": "j.boggiano@seld.be",
- "homepage": "http://seld.be"
- }
- ]
-}
-```
+ {
+ "authors": [
+ {
+ "name": "Nils Adermann",
+ "email": "naderman@naderman.de",
+ "homepage": "http://www.naderman.de"
+ },
+ {
+ "name": "Jordi Boggiano",
+ "email": "j.boggiano@seld.be",
+ "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.*"
+ {
+ "require": {
+ "monolog/monolog": "1.0.*"
+ }
}
-}
-```
Optional.
@@ -194,13 +190,11 @@ package root.
Example:
-```json
-{
- "autoload": {
- "psr-0": { "Monolog": "src/" }
+ {
+ "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"
-}
-```
+ {
+ "autoload": {
+ "psr-0": { "Symfony\\Component\\Yaml": "" }
+ },
+ "target-dir": "Symfony/Component/Yaml"
+ }
Optional.
@@ -259,40 +251,38 @@ For more information on any of these, see [Repositories].
Example:
-```json
-{
- "repositories": [
- {
- "type": "composer",
- "url": "http://packages.example.com"
- },
- {
- "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/"
+ {
+ "repositories": [
+ {
+ "type": "composer",
+ "url": "http://packages.example.com"
+ },
+ {
+ "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/"
+ }
}
}
- }
- ]
-}
-```
+ ]
+ }
> **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
- }
- ]
-}
-```
+ {
+ "repositories": [
+ {
+ "packagist": false
+ }
+ ]
+ }
## config
@@ -327,13 +315,11 @@ The following options are supported:
Example:
-```json
-{
- "config": {
- "bin-dir": "bin"
+ {
+ "config": {
+ "bin-dir": "bin"
+ }
}
-}
-```
## scripts
@@ -368,35 +354,31 @@ handle it.
Example:
-```json
-{
- "scripts": {
- "post-install-cmd": [
- "Acme\\ScriptHandler::doSomething"
- ]
+ {
+ "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
-{
- static public function doSomething(Event $event)
+ class ScriptHandler
{
- $composer = $event->getComposer();
+ static public function doSomething(Event $event)
+ {
+ $composer = $event->getComposer();
- // custom logic
+ // 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.
View
114 doc/05-repositories.md
@@ -52,18 +52,16 @@ 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",
- "versions": {
- "master-dev": { @composer.json },
- "1.0.0": { @composer.json }
+ {
+ "vendor/packageName": {
+ "name": "vendor/packageName",
+ "description": "Package description",
+ "versions": {
+ "master-dev": { @composer.json },
+ "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"
+ {
+ "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,19 +107,17 @@ point to your custom branch.
Example assuming you patched monolog to fix a bug in the `bugfix` branch:
-```json
-{
- "repositories": [
- {
- "type": "vcs",
- "url": "http://github.com/igorw/monolog"
+ {
+ "repositories": [
+ {
+ "type": "vcs",
+ "url": "http://github.com/igorw/monolog"
+ }
+ ],
+ "require": {
+ "monolog/monolog": "dev-bugfix"
}
- ],
- "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,19 +148,17 @@ avoid conflicts.
Example using `pear2.php.net`:
-```json
-{
- "repositories": [
- {
- "type": "pear",
- "url": "http://pear2.php.net"
+ {
+ "repositories": [
+ {
+ "type": "pear",
+ "url": "http://pear2.php.net"
+ }
+ ],
+ "require": {
+ "pear-pear2/PEAR2_HTTP_Request": "*"
}
- ],
- "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,31 +179,29 @@ minimum required fields are `name`, `version`, and either of `dist` or
Here is an example for the smarty template engine:
-```json
-{
- "repositories": [
- {
- "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/"
+ {
+ "repositories": [
+ {
+ "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/"
+ }
}
}
+ ],
+ "require": {
+ "smarty/smarty": "3.1.*"
}
- ],
- "require": {
- "smarty/smarty": "3.1.*"
}
-}
-```
Typically you would leave the source part off, as you don't really need it.
View
40 doc/articles/scripts.md
@@ -34,33 +34,29 @@ functionality.
Script definition example:
-```json
-{
- "scripts": {
- "post-update-cmd": "MyVendor\\MyClass::postUpdate",
- "post-package-install": ["MyVendor\\MyClass::postPackageInstall"]
+ {
+ "scripts": {
+ "post-update-cmd": "MyVendor\\MyClass::postUpdate",
+ "post-package-install": ["MyVendor\\MyClass::postPackageInstall"]
+ }
}
-}
-```
Script listener example:
-```php
-<?php
-
-namespace MyVendor;
+ <?php
-class MyClass
-{
- public static function postUpdate($event)
- {
- // do stuff
- }
+ namespace MyVendor;
- public static function postPackageInstall($event)
+ class MyClass
{
- $installedPackage = $event->getOperation()->getPackage();
- // do stuff
+ public static function postUpdate($event)
+ {
+ // do stuff
+ }
+
+ public static function postPackageInstall($event)
+ {
+ $installedPackage = $event->getOperation()->getPackage();
+ // do stuff
+ }
}
-}
-```
View
40 doc/articles/vendor-bins.md
@@ -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"]
-}
-```
+ {
+ "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"]
-}
-```
+ {
+ "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": "*"
+ {
+ "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"
+ {
+ "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
Please sign in to comment.
Something went wrong with that request. Please try again.