Clean up documentation
Gabriel Caruso
parent
6717cf1956
commit
486e580db2
|
|
@ -220,7 +220,6 @@ If you do not specify a package, composer will prompt you to search for a packag
|
|||
Implicitly enables `--optimize-autoloader`.
|
||||
* **--apcu-autoloader:** Use APCu to cache found/not-found classes.
|
||||
|
||||
|
||||
## remove
|
||||
|
||||
The `remove` command removes packages from the `composer.json` file from
|
||||
|
|
|
|||
|
|
@ -356,7 +356,6 @@ Example:
|
|||
> use and require. Alternatively you may use third party tools to analyze
|
||||
> your project for the list of extensions used.
|
||||
|
||||
|
||||
#### require
|
||||
|
||||
Lists packages required by this package. The package will not be installed
|
||||
|
|
|
|||
|
|
@ -205,7 +205,7 @@ project to use the patched version. If the library is on GitHub (this is the
|
|||
case most of the time), you can simply fork it there and push your changes to
|
||||
your fork. After that you update the project's `composer.json`. All you have
|
||||
to do is add your fork as a repository and update the version constraint to
|
||||
point to your custom branch. In `composer.json`, you should prefix your custom
|
||||
point to your custom branch. In `composer.json`, you should prefix your custom
|
||||
branch name with `"dev-"`. For version constraint naming conventions see
|
||||
[Libraries](02-libraries.md) for more information.
|
||||
|
||||
|
|
@ -300,18 +300,17 @@ Please note:
|
|||
|
||||
The BitBucket driver uses OAuth to access your private repositories via the BitBucket REST APIs and you will need to create an OAuth consumer to use the driver, please refer to [Atlassian's Documentation](https://confluence.atlassian.com/bitbucket/oauth-on-bitbucket-cloud-238027431.html). You will need to fill the callback url with something to satisfy BitBucket, but the address does not need to go anywhere and is not used by Composer.
|
||||
|
||||
After creating an OAuth consumer in the BitBucket control panel, you need to setup your auth.json file with
|
||||
After creating an OAuth consumer in the BitBucket control panel, you need to setup your auth.json file with
|
||||
the credentials like this (more info [here](https://getcomposer.org/doc/06-config.md#bitbucket-oauth)):
|
||||
```json
|
||||
{
|
||||
"config": {
|
||||
"bitbucket-oauth": {
|
||||
"bitbucket.org": {
|
||||
"consumer-key": "myKey",
|
||||
"consumer-key": "myKey",
|
||||
"consumer-secret": "mySecret"
|
||||
}
|
||||
}
|
||||
|
||||
}
|
||||
}
|
||||
```
|
||||
|
|
@ -518,7 +517,7 @@ Typically you would leave the source part off, as you don't really need it.
|
|||
> reference you will have to delete the package to force an update, and will
|
||||
> have to deal with an unstable lock file.
|
||||
|
||||
The `"package"` key in a `package` repository may be set to an array to define multiple versions of a package:
|
||||
The `"package"` key in a `package` repository may be set to an array to define multiple versions of a package:
|
||||
|
||||
```json
|
||||
{
|
||||
|
|
@ -708,7 +707,7 @@ You can disable the default Packagist.org repository by adding this to your
|
|||
|
||||
You can disable Packagist.org globally by using the global config flag:
|
||||
|
||||
```
|
||||
```bash
|
||||
composer config -g repo.packagist false
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -65,8 +65,8 @@ is a dependency of your local project.
|
|||
|
||||
For this reason, you can alias packages in your `require` and `require-dev`
|
||||
fields. Let's say you found a bug in the `monolog/monolog` package. You cloned
|
||||
[Monolog](https://github.com/Seldaek/monolog) on GitHub and fixed the issue in
|
||||
a branch named `bugfix`. Now you want to install that version of monolog in your
|
||||
[Monolog](https://github.com/Seldaek/monolog) on GitHub and fixed the issue in
|
||||
a branch named `bugfix`. Now you want to install that version of monolog in your
|
||||
local project.
|
||||
|
||||
You are using `symfony/monolog-bundle` which requires `monolog/monolog` version
|
||||
|
|
|
|||
|
|
@ -53,7 +53,6 @@ result in slow filesystem checks. To solve this issue two Level 2 optimization
|
|||
options exist, and you can decide to enable either if you have a lot of
|
||||
class_exists checks that are done for classes that do not exist in your project.
|
||||
|
||||
|
||||
## Optimization Level 2/A: Authoritative class maps
|
||||
|
||||
### How to run it?
|
||||
|
|
@ -82,7 +81,6 @@ then you might experience "class not found" issues in production. Enable this wi
|
|||
> Note: This can not be combined with Level 2/B optimizations. You have to choose one as
|
||||
> they address the same issue in different ways.
|
||||
|
||||
|
||||
## Optimization Level 2/B: APCu cache
|
||||
|
||||
### How to run it?
|
||||
|
|
|
|||
|
|
@ -336,7 +336,6 @@ is set to true.
|
|||
* `notify-batch`: optional, specify a URL that will be called every time a
|
||||
user installs a package. See [notify-batch].
|
||||
|
||||
|
||||
[ssh2 context options]: https://secure.php.net/manual/en/wrappers.ssh2.php#refsect1-wrappers.ssh2-options
|
||||
[ssl context options]: https://secure.php.net/manual/en/context.ssl.php
|
||||
[Twig]: https://twig.sensiolabs.org/
|
||||
|
|
|
|||
|
|
@ -191,8 +191,8 @@ with [`Composer\Composer`][4]'s internal state, by providing explicit extension
|
|||
for common plugin requirements.
|
||||
|
||||
Capable Plugins classes must implement the [`Composer\Plugin\Capable`][8] interface
|
||||
and declare their capabilities in the `getCapabilities()` method.
|
||||
This method must return an array, with the _key_ as a Composer Capability class name,
|
||||
and declare their capabilities in the `getCapabilities()` method.
|
||||
This method must return an array, with the _key_ as a Composer Capability class name,
|
||||
and the _value_ as the Plugin's own implementation class name of said Capability:
|
||||
|
||||
```php
|
||||
|
|
|
|||
|
|
@ -15,7 +15,6 @@ the Composer execution process.
|
|||
> executed. If a dependency of the root package specifies its own scripts,
|
||||
> Composer does not execute those additional scripts.
|
||||
|
||||
|
||||
## Event names
|
||||
|
||||
Composer fires the following named events during its execution process:
|
||||
|
|
|
|||
|
|
@ -244,7 +244,7 @@ following workarounds:
|
|||
On linux, it seems that running this command helps to make ipv4 traffic have a
|
||||
higher prio than ipv6, which is a better alternative than disabling ipv6 entirely:
|
||||
|
||||
```Bash
|
||||
```bash
|
||||
sudo sh -c "echo 'precedence ::ffff:0:0/96 100' >> /etc/gai.conf"
|
||||
```
|
||||
|
||||
|
|
@ -256,13 +256,13 @@ On windows the only way is to disable ipv6 entirely I am afraid (either in windo
|
|||
|
||||
Get name of your network device:
|
||||
|
||||
```
|
||||
```bash
|
||||
networksetup -listallnetworkservices
|
||||
```
|
||||
|
||||
Disable IPv6 on that device (in this case "Wi-Fi"):
|
||||
|
||||
```
|
||||
```bash
|
||||
networksetup -setv6off Wi-Fi
|
||||
```
|
||||
|
||||
|
|
@ -270,7 +270,7 @@ Run composer ...
|
|||
|
||||
You can enable IPv6 again with:
|
||||
|
||||
```
|
||||
```bash
|
||||
networksetup -setv6automatic Wi-Fi
|
||||
```
|
||||
|
||||
|
|
@ -288,7 +288,7 @@ The reason for this is a SSH Bug: https://bugzilla.mindrot.org/show_bug.cgi?id=1
|
|||
|
||||
As a workaround, open a SSH connection to your Git host before running Composer:
|
||||
|
||||
```
|
||||
```bash
|
||||
ssh -t git@mygitserver.tld
|
||||
composer update
|
||||
```
|
||||
|
|
|
|||
|
|
@ -13,7 +13,6 @@ If a package contains other scripts that are not needed by the package
|
|||
users (like build or compile scripts) that code should not be listed
|
||||
as a vendor binary.
|
||||
|
||||
|
||||
## How is it defined?
|
||||
|
||||
It is defined by adding the `bin` key to a project's `composer.json`.
|
||||
|
|
@ -34,12 +33,10 @@ for any project that **depends** on that project.
|
|||
This is a convenient way to expose useful scripts that would
|
||||
otherwise be hidden deep in the `vendor/` directory.
|
||||
|
||||
|
||||
## What happens when Composer is run on a composer.json that defines vendor binaries?
|
||||
|
||||
For the binaries that a package defines directly, nothing happens.
|
||||
|
||||
|
||||
## What happens when Composer is run on a composer.json that has dependencies with vendor binaries listed?
|
||||
|
||||
Composer looks for the binaries defined in all of the dependencies. A
|
||||
|
|
@ -75,7 +72,6 @@ In this case, Composer will make `vendor/my-vendor/project-a/bin/project-a-bin`
|
|||
available as `vendor/bin/project-a-bin`. On a Unix-like platform
|
||||
this is accomplished by creating a symlink.
|
||||
|
||||
|
||||
## What about Windows and .bat files?
|
||||
|
||||
Packages managed entirely by Composer do not *need* to contain any
|
||||
|
|
@ -90,7 +86,6 @@ Packages that need to support workflows that may not include Composer
|
|||
are welcome to maintain custom `.bat` files. In this case, the package
|
||||
should **not** list the `.bat` file as a binary as it is not needed.
|
||||
|
||||
|
||||
## Can vendor binaries be installed somewhere other than vendor/bin?
|
||||
|
||||
Yes, there are two ways an alternate vendor binary location can be specified:
|
||||
|
|
|
|||
|
|
@ -74,7 +74,7 @@ correct location in your `vendor` directory.
|
|||
|
||||
### Branches
|
||||
|
||||
If you want Composer to check out a branch instead of a tag, you need to point it to the branch using the special `dev-*` prefix (or sometimes suffix; see below). If you're checking out a branch, it's assumed that you want to *work* on the branch and Composer actually clones the repo into the correct place in your `vendor` directory. For tags, it just copies the right files without actually cloning the repo. (You can modify this behavior with --prefer-source and --prefer-dist, see [install options](../03-cli.md#install).)
|
||||
If you want Composer to check out a branch instead of a tag, you need to point it to the branch using the special `dev-*` prefix (or sometimes suffix; see below). If you're checking out a branch, it's assumed that you want to *work* on the branch and Composer actually clones the repo into the correct place in your `vendor` directory. For tags, it just copies the right files without actually cloning the repo. (You can modify this behavior with --prefer-source and --prefer-dist, see [install options](../03-cli.md#install).)
|
||||
|
||||
In the above example, if you wanted to check out the `my-feature` branch, you would specify `dev-my-feature` as the version constraint in your `require` clause. This would result in Composer cloning the `my-library` repository into my `vendor` directory and checking out the `my-feature` branch.
|
||||
|
||||
|
|
@ -201,7 +201,7 @@ setting. All available stability flags are listed on the minimum-stability
|
|||
section of the [schema page](../04-schema.md#minimum-stability).
|
||||
|
||||
## Summary
|
||||
```
|
||||
```json
|
||||
"require": {
|
||||
"vendor/package": "1.3.2", // exactly 1.3.2
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# How do I install untrusted packages safely? Is it safe to run Composer as superuser or root?
|
||||
|
||||
Certain Composer commands, including `exec`, `install`, and `update` allow third party code to
|
||||
Certain Composer commands, including `exec`, `install`, and `update` allow third party code to
|
||||
execute on your system. This is from its "plugins" and "scripts" features. Plugins and scripts have
|
||||
full access to the user account which runs Composer. For this reason, it is strongly advised to
|
||||
**avoid running Composer as super-user/root**.
|
||||
|
|
|
|||
|
|
@ -20,4 +20,3 @@ All these repositories contain the following packages.
|
|||
* `bar/baz` has a 1.0.0 version and 1.0.x-dev as well as dev-default branches.
|
||||
Additionally, 1.1.x-dev is a branch alias for dev-default.
|
||||
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue