Capitalize Composer in the docs
parent
6aec6ecbfa
commit
bb128c465c
|
@ -230,7 +230,7 @@ to the command.
|
|||
php composer.phar require "vendor/package:2.*" vendor/package2:dev-master
|
||||
```
|
||||
|
||||
If you do not specify a package, composer will prompt you to search for a package, and given results, provide a list of matches to require.
|
||||
If you do not specify a package, Composer will prompt you to search for a package, and given results, provide a list of matches to require.
|
||||
|
||||
### Options
|
||||
|
||||
|
@ -694,7 +694,7 @@ If Composer was not installed as a PHAR, this command is not available.
|
|||
|
||||
## config
|
||||
|
||||
The `config` command allows you to edit composer config settings and repositories
|
||||
The `config` command allows you to edit Composer config settings and repositories
|
||||
in either the local `composer.json` file or the global `config.json` file.
|
||||
|
||||
Additionally it lets you edit most properties in the local `composer.json`.
|
||||
|
@ -907,7 +907,7 @@ runs.
|
|||
|
||||
### Options
|
||||
|
||||
* **--list (-l):** List the available composer binaries.
|
||||
* **--list (-l):** List the available Composer binaries.
|
||||
|
||||
## diagnose
|
||||
|
||||
|
@ -1043,7 +1043,7 @@ configuration in the project's `composer.json` always wins.
|
|||
### COMPOSER_HTACCESS_PROTECT
|
||||
|
||||
Defaults to `1`. If set to `0`, Composer will not create `.htaccess` files in the
|
||||
composer home, cache, and data directories.
|
||||
Composer home, cache, and data directories.
|
||||
|
||||
### COMPOSER_MEMORY_LIMIT
|
||||
|
||||
|
|
|
@ -791,7 +791,7 @@ The following repository types are supported:
|
|||
* **vcs:** The version control system repository can fetch packages from git,
|
||||
svn, fossil and hg repositories.
|
||||
* **package:** If you depend on a project that does not have any support for
|
||||
composer whatsoever you can define the package inline using a `package`
|
||||
Composer whatsoever you can define the package inline using a `package`
|
||||
repository. You basically inline the `composer.json` object.
|
||||
|
||||
For more information on any of these, see [Repositories](05-repositories.md).
|
||||
|
|
|
@ -199,7 +199,7 @@ the 404-requests, you can also specify an `"available-packages"` key in
|
|||
`packages.json` which should be an array with all the package names that your
|
||||
repository contain. Alternatively you can specify an
|
||||
`"available-package-patterns"` key which is an array of package name patterns
|
||||
(with `*` matching any string, e.g. `vendor/*` would make composer look up
|
||||
(with `*` matching any string, e.g. `vendor/*` would make Composer look up
|
||||
every matching package name in this repository).
|
||||
|
||||
This field is optional.
|
||||
|
@ -411,7 +411,7 @@ attempt to use github's zip files.
|
|||
|
||||
Please note:
|
||||
* **To let Composer choose which driver to use** the repository type needs to be defined as "vcs"
|
||||
* **If you already used a private repository**, this means Composer should have cloned it in cache. If you want to install the same package with drivers, remember to launch the command `composer clearcache` followed by the command `composer update` to update composer cache and install the package from dist.
|
||||
* **If you already used a private repository**, this means Composer should have cloned it in cache. If you want to install the same package with drivers, remember to launch the command `composer clearcache` followed by the command `composer update` to update Composer cache and install the package from dist.
|
||||
|
||||
#### BitBucket Driver Configuration
|
||||
|
||||
|
|
|
@ -344,7 +344,7 @@ Example:
|
|||
## htaccess-protect
|
||||
|
||||
Defaults to `true`. If set to `false`, Composer will not create `.htaccess` files
|
||||
in the composer home, cache, and data directories.
|
||||
in the Composer home, cache, and data directories.
|
||||
|
||||
## lock
|
||||
|
||||
|
|
|
@ -89,7 +89,7 @@ Add this to your project's root `composer.json`:
|
|||
}
|
||||
```
|
||||
|
||||
Or let composer add it for you with:
|
||||
Or let Composer add it for you with:
|
||||
|
||||
```
|
||||
php composer.phar require monolog/monolog:"dev-bugfix as 1.0.x-dev"
|
||||
|
|
|
@ -132,7 +132,7 @@ it, pass the VCS repository URL as an optional argument:
|
|||
|
||||
## Usage
|
||||
|
||||
In your projects all you need to add now is your own composer repository using
|
||||
In your projects all you need to add now is your own Composer repository using
|
||||
the `packages.example.org` as URL, then you can require your private packages
|
||||
and everything should work smoothly. You don't need to copy all your
|
||||
repositories in every project anymore. Only that one unique repository that
|
||||
|
@ -323,7 +323,7 @@ is set to true.
|
|||
|
||||
* `providers`: optional, `false` by default, when enabled (`true`) each
|
||||
package will be dumped into a separate include file which will be only
|
||||
loaded by composer when the package is really required. Speeds up composer
|
||||
loaded by Composer when the package is really required. Speeds up composer
|
||||
handling for repositories with huge number of packages like f.i. packagist.
|
||||
* `output-dir`: optional, defines where to output the repository files if not
|
||||
provided as an argument when calling the `build` command.
|
||||
|
|
|
@ -62,7 +62,7 @@ You can also filter packages which a repository will be able to load, either by
|
|||
selecting which ones you want, or by excluding those you do not want.
|
||||
|
||||
For example here we want to pick only the package `foo/bar` and all the packages from
|
||||
`some-vendor/` from this composer repository.
|
||||
`some-vendor/` from this Composer repository.
|
||||
|
||||
```json
|
||||
{
|
||||
|
|
|
@ -33,9 +33,9 @@ An example where we have two branches:
|
|||
To resolve the conflict when we merge these two branches:
|
||||
|
||||
- We choose the branch that has the most changes, and accept the `composer.json` and `composer.lock`
|
||||
files from that branch. In this case, we choose the composer files from branch 2.
|
||||
files from that branch. In this case, we choose the Composer files from branch 2.
|
||||
- We reapply the changes from the other branch (branch 1). In this case we have to run
|
||||
```composer require package/A``` again.
|
||||
`composer require package/A` again.
|
||||
|
||||
## 2. Validating your merged files
|
||||
|
||||
|
|
|
@ -84,7 +84,7 @@ indirectly) back on the root package itself, issues can occur in two cases:
|
|||
## I have a dependency which contains a "repositories" definition in its composer.json, but it seems to be ignored.
|
||||
|
||||
The [`repositories`](../04-schema.md#repositories) configuration property is defined as [root-only](../04-schema.md#root-package). It is not inherited. You can read more about the reasons behind this in the "[why can't
|
||||
composer load repositories recursively?](../faqs/why-can't-composer-load-repositories-recursively.md)" article.
|
||||
Composer load repositories recursively?](../faqs/why-can't-composer-load-repositories-recursively.md)" article.
|
||||
The simplest work-around to this limitation, is moving or duplicating the `repositories` definition into your root
|
||||
composer.json.
|
||||
|
||||
|
@ -189,7 +189,7 @@ manually create a token using the [procedure documented here](authentication-for
|
|||
Now Composer should install/update without asking for authentication.
|
||||
|
||||
## proc_open(): fork failed errors
|
||||
If composer shows proc_open() fork failed on some commands:
|
||||
If Composer shows proc_open() fork failed on some commands:
|
||||
|
||||
`PHP Fatal error: Uncaught exception 'ErrorException' with message 'proc_open(): fork failed - Cannot allocate memory' in phar`
|
||||
|
||||
|
@ -216,7 +216,7 @@ You can make a permanent swap file following this [tutorial](https://www.digital
|
|||
|
||||
## proc_open(): failed to open stream errors (Windows)
|
||||
|
||||
If composer shows proc_open(NUL) errors on Windows:
|
||||
If Composer shows proc_open(NUL) errors on Windows:
|
||||
|
||||
`proc_open(NUL): failed to open stream: No such file or directory`
|
||||
|
||||
|
@ -288,7 +288,7 @@ Disable IPv6 on that device (in this case "Wi-Fi"):
|
|||
networksetup -setv6off Wi-Fi
|
||||
```
|
||||
|
||||
Run composer ...
|
||||
Run Composer ...
|
||||
|
||||
You can enable IPv6 again with:
|
||||
|
||||
|
|
|
@ -78,7 +78,7 @@ If you want Composer to check out a branch instead of a tag, you need to point i
|
|||
|
||||
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.
|
||||
|
||||
When branch names look like versions, we have to clarify for composer that we're trying to check out a branch and not a tag. In the above example, we have two version branches: `v1` and `v2`. To get Composer to check out one of these branches, you must specify a version constraint that looks like this: `v1.x-dev`. The `.x` is an arbitrary string that Composer requires to tell it that we're talking about the `v1` branch and not a `v1` tag (alternatively, you can name the branch `v1.x` instead of `v1`). In the case of a branch with a version-like name (`v1`, in this case), you append `-dev` as a suffix, rather than using `dev-` as a prefix.
|
||||
When branch names look like versions, we have to clarify for Composer that we're trying to check out a branch and not a tag. In the above example, we have two version branches: `v1` and `v2`. To get Composer to check out one of these branches, you must specify a version constraint that looks like this: `v1.x-dev`. The `.x` is an arbitrary string that Composer requires to tell it that we're talking about the `v1` branch and not a `v1` tag (alternatively, you can name the branch `v1.x` instead of `v1`). In the case of a branch with a version-like name (`v1`, in this case), you append `-dev` as a suffix, rather than using `dev-` as a prefix.
|
||||
|
||||
### Stabilities
|
||||
|
||||
|
@ -213,7 +213,7 @@ Examples:
|
|||
|
||||
To allow various stabilities without enforcing them at the constraint level
|
||||
however, you may use [stability-flags](../04-schema.md#package-links) like
|
||||
`@<stability>` (e.g. `@dev`) to let composer know that a given package
|
||||
`@<stability>` (e.g. `@dev`) to let Composer know that a given package
|
||||
can be installed in a different stability than your default minimum-stability
|
||||
setting. All available stability flags are listed on the minimum-stability
|
||||
section of the [schema page](../04-schema.md#minimum-stability).
|
||||
|
|
|
@ -26,7 +26,7 @@ If you really feel like you must do this, you have a few options:
|
|||
you can add them to your git repo. You can do that with `rm -rf vendor/**/.git`
|
||||
in ZSH or `find vendor/ -type d -name ".git" -exec rm -rf {} \;` in Bash.
|
||||
But this means you will have to delete those dependencies from disk before
|
||||
running composer update.
|
||||
running `composer update`.
|
||||
4. Add a .gitignore rule (`/vendor/**/.git`) to ignore all the vendor `.git` folders.
|
||||
This approach does not require that you delete dependencies from disk prior to
|
||||
running a composer update.
|
||||
running a `composer update`.
|
||||
|
|
Loading…
Reference in New Issue