dependabot-composer 0.111.17 → 0.111.18

data/helpers/vendor/composer/composer/doc/articles/troubleshooting.md

@@ -1,309 +0,0 @@
-<!--
-    tagline: Solving problems
--->
-# Troubleshooting
-
-This is a list of common pitfalls on using Composer, and how to avoid them.
-
-## General
-
-1. Before asking anyone, run [`composer diagnose`](../03-cli.md#diagnose) to check
-   for common problems. If it all checks out, proceed to the next steps.
-
-2. When facing any kind of problems using Composer, be sure to **work with the
-   latest version**. See [self-update](../03-cli.md#self-update) for details.
-
-3. Make sure you have no problems with your setup by running the installer's
-   checks via `curl -sS https://getcomposer.org/installer | php -- --check`.
-
-4. Ensure you're **installing vendors straight from your `composer.json`** via
-   `rm -rf vendor && composer update -v` when troubleshooting, excluding any
-   possible interferences with existing vendor installations or `composer.lock`
-   entries.
-
-5. Try clearing Composer's cache by running `composer clear-cache`.
-
-## Package not found
-
-1. Double-check you **don't have typos** in your `composer.json` or repository
-   branches and tag names.
-
-2. Be sure to **set the right
-   [minimum-stability](../04-schema.md#minimum-stability)**. To get started or be
-   sure this is no issue, set `minimum-stability` to "dev".
-
-3. Packages **not coming from [Packagist](https://packagist.org/)** should
-   always be **defined in the root package** (the package depending on all
-   vendors).
-
-4. Use the **same vendor and package name** throughout all branches and tags of
-   your repository, especially when maintaining a third party fork and using
-   `replace`.
-
-5. If you are updating to a recently published version of a package, be aware that
-   Packagist has a delay of up to 1 minute before new packages are visible to Composer.
-
-6. If you are updating a single package, it may depend on newer versions itself.
-   In this case add the `--with-dependencies` argument **or** add all dependencies which
-   need an update to the command.
-
-## Package not found on travis-ci.org
-
-1. Check the ["Package not found"](#package-not-found) item above.
-
-2. If the package tested is a dependency of one of its dependencies (cyclic
-   dependency), the problem might be that Composer is not able to detect the version
-   of the package properly. If it is a git clone it is generally alright and Composer
-   will detect the version of the current branch, but travis does shallow clones so
-   that process can fail when testing pull requests and feature branches in general.
-   The best solution is to define the version you are on via an environment variable
-   called COMPOSER_ROOT_VERSION. You set it to `dev-master` for example to define
-   the root package's version as `dev-master`.
-   Use: `before_script: COMPOSER_ROOT_VERSION=dev-master composer install` to export
-   the variable for the call to composer.
-
-## Package not found in a Jenkins-build
-
-1. Check the ["Package not found"](#package-not-found) item above.
-2. Reason for failing is similar to the problem which can occur on travis-ci.org: The
-   git-clone / checkout within Jenkins leaves the branch in a "detached HEAD"-state. As
-   a result, Composer is not able to identify the version of the current checked out branch
-   and may not be able to resolve a cyclic dependency. To solve this problem, you can use
-   the "Additional Behaviours" -> "Check out to specific local branch" in your Git-settings
-   for your Jenkins-job, where your "local branch" shall be the same branch as you are
-   checking out. Using this, the checkout will not be in detached state any more and cyclic
-   dependency is recognized correctly.
-
-## 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.
-The simplest work-around to this limitation, is moving or duplicating the `repositories` definition into your root
-composer.json.
-
-## I have locked a dependency to a specific commit but get unexpected results.
-
-While Composer supports locking dependencies to a specific commit using the `#commit-ref` syntax, there are certain
-caveats that one should take into account. The most important one is [documented](../04-schema.md#package-links), but
-frequently overlooked:
-
-> **Note:** While this is convenient at times, it should not be how you use
-> packages in the long term because it comes with a technical limitation. The
-> composer.json metadata will still be read from the branch name you specify
-> before the hash. Because of that in some cases it will not be a practical
-> workaround, and you should always try to switch to tagged releases as soon
-> as you can.
-
-There is no simple work-around to this limitation. It is therefore strongly recommended that you do not use it.
-
-## Need to override a package version
-
-Let's say your project depends on package A, which in turn depends on a specific
-version of package B (say 0.1). But you need a different version of said package B (say 0.11).
-
-You can fix this by aliasing version 0.11 to 0.1:
-
-composer.json:
-
-```json
-{
-    "require": {
-        "A": "0.2",
-        "B": "0.11 as 0.1"
-    }
-}
-```
-
-See [aliases](aliases.md) for more information.
-
-## Memory limit errors
-
-Composer may sometimes fail on some commands with this message:
-
-`PHP Fatal error:  Allowed memory size of XXXXXX bytes exhausted <...>`
-
-In this case, the PHP `memory_limit` should be increased.
-
-> **Note:** Composer internally increases the `memory_limit` to `1.5G`.
-
-To get the current `memory_limit` value, run:
-
-```sh
-php -r "echo ini_get('memory_limit').PHP_EOL;"
-```
-
-Try increasing the limit in your `php.ini` file (ex. `/etc/php5/cli/php.ini` for
-Debian-like systems):
-
-```ini
-; Use -1 for unlimited or define an explicit value like 2G
-memory_limit = -1
-```
-
-Composer also respects a memory limit defined by the `COMPOSER_MEMORY_LIMIT` environment variable:
-
-```sh
-COMPOSER_MEMORY_LIMIT=-1 composer.phar <...>
-```
-
-Or, you can increase the limit with a command-line argument:
-
-```sh
-php -d memory_limit=-1 composer.phar <...>
-```
-
-This issue can also happen on cPanel instances, when the shell fork bomb protection is activated. For more information, see the [documentation](https://documentation.cpanel.net/display/68Docs/Shell+Fork+Bomb+Protection) of the fork bomb feature on the cPanel site.
-
-## Xdebug impact on Composer
-
-To improve performance when the xdebug extension is enabled, Composer automatically restarts PHP without it.
-You can override this behavior by using an environment variable: `COMPOSER_ALLOW_XDEBUG=1`.
-
-Composer will always show a warning if xdebug is being used, but you can override this with an environment variable:
-`COMPOSER_DISABLE_XDEBUG_WARN=1`. If you see this warning unexpectedly, then the restart process has failed:
-please report this [issue](https://github.com/composer/composer/issues).
-
-## "The system cannot find the path specified" (Windows)
-
-1. Open regedit.
-2. Search for an `AutoRun` key inside `HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor`,
-   `HKEY_CURRENT_USER\Software\Microsoft\Command Processor`
-   or `HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Command Processor`.
-3. Check if it contains any path to non-existent file, if it's the case, remove them.
-
-## API rate limit and OAuth tokens
-
-Because of GitHub's rate limits on their API it can happen that Composer prompts
-for authentication asking your username and password so it can go ahead with its work.
-
-If you would prefer not to provide your GitHub credentials to Composer you can
-manually create a token using the following procedure:
-
-1. [Create](https://github.com/settings/tokens) an OAuth token on GitHub.
-[Read more](https://github.com/blog/1509-personal-api-tokens) on this.
-
-2. Add it to the configuration running `composer config -g github-oauth.github.com <oauthtoken>`
-
-Now Composer should install/update without asking for authentication.
-
-## proc_open(): fork failed errors
-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`
-
-This could be happening because the VPS runs out of memory and has no Swap space enabled.
-
-```sh
-free -m
-
-total used free shared buffers cached
-Mem: 2048 357 1690 0 0 237
--/+ buffers/cache: 119 1928
-Swap: 0 0 0
-```
-
-To enable the swap you can use for example:
-
-```sh
-/bin/dd if=/dev/zero of=/var/swap.1 bs=1M count=1024
-/sbin/mkswap /var/swap.1
-/sbin/swapon /var/swap.1
-```
-You can make a permanent swap file following this [tutorial](https://www.digitalocean.com/community/tutorials/how-to-add-swap-on-ubuntu-14-04).
-
-## Degraded Mode
-
-Due to some intermittent issues on Travis and other systems, we introduced a
-degraded network mode which helps Composer finish successfully but disables
-a few optimizations. This is enabled automatically when an issue is first
-detected. If you see this issue sporadically you probably don't have to worry
-(a slow or overloaded network can also cause those time outs), but if it
-appears repeatedly you might want to look at the options below to identify
-and resolve it.
-
-If you have been pointed to this page, you want to check a few things:
-
-- If you are using ESET antivirus, go in "Advanced Settings" and disable "HTTP-scanner"
-  under "web access protection"
-- If you are using IPv6, try disabling it. If that solves your issues, get in touch
-  with your ISP or server host, the problem is not at the Packagist level but in the
-  routing rules between you and Packagist (i.e. the internet at large). The best way to get
-  these fixed is raise awareness to the network engineers that have the power to fix it.
-  Take a look at the next section for IPv6 workarounds.
-
-- If none of the above helped, please report the error.
-
-## Operation timed out (IPv6 issues)
-
-You may run into errors if IPv6 is not configured correctly. A common error is:
-
-```
-The "https://getcomposer.org/version" file could not be downloaded: failed to
-open stream: Operation timed out
-```
-
-We recommend you fix your IPv6 setup. If that is not possible, you can try the
-following workarounds:
-
-**Workaround Linux:**
-
-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
-sudo sh -c "echo 'precedence ::ffff:0:0/96 100' >> /etc/gai.conf"
-```
-
-**Workaround Windows:**
-
-On windows the only way is to disable ipv6 entirely I am afraid (either in windows or in your home router).
-
-**Workaround Mac OS X:**
-
-Get name of your network device:
-
-```bash
-networksetup -listallnetworkservices
-```
-
-Disable IPv6 on that device (in this case "Wi-Fi"):
-
-```bash
-networksetup -setv6off Wi-Fi
-```
-
-Run composer ...
-
-You can enable IPv6 again with:
-
-```bash
-networksetup -setv6automatic Wi-Fi
-```
-
-That said, if this fixes your problem, please talk to your ISP about it to
-try and resolve the routing errors. That's the best way to get things resolved
-for everyone.
-
-## Composer hangs with SSH ControlMaster
-
-When you try to install packages from a Git repository and you use the `ControlMaster`
-setting for your SSH connection, Composer might hang endlessly and you see a `sh`
-process in the `defunct` state in your process list.
-
-The reason for this is a SSH Bug: https://bugzilla.mindrot.org/show_bug.cgi?id=1988
-
-As a workaround, open a SSH connection to your Git host before running Composer:
-
-```bash
-ssh -t git@mygitserver.tld
-composer update
-```
-
-See also https://github.com/composer/composer/issues/4180 for more information.
-
-## Zip archives are not unpacked correctly.
-
-Composer can unpack zipballs using either a system-provided `unzip` utility or PHP's
-native `ZipArchive` class. The `ZipArchive` class is preferred on Windows. On other
-OSes where ZIP files can contain permissions and symlinks, the `unzip` utility is
-preferred. You're advised to install it if you need these features.

data/helpers/vendor/composer/composer/doc/articles/vendor-binaries.md

@@ -1,110 +0,0 @@
-<!--
-    tagline: Expose command-line scripts from packages
--->
-
-# Vendor binaries and the `vendor/bin` directory
-
-## What is a vendor binary?
-
-Any command line script that a Composer package would like to pass along
-to a user who installs the package should be listed as a vendor binary.
-
-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`.
-It is specified as an array of files so multiple binaries can be added
-for any given project.
-
-```json
-{
-    "bin": ["bin/my-script", "bin/my-other-script"]
-}
-```
-
-## What does defining a vendor binary in composer.json do?
-
-It instructs Composer to install the package's binaries to `vendor/bin`
-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
-symlink is created from each dependency's binaries to `vendor/bin`.
-
-Say package `my-vendor/project-a` has binaries 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",
-    "require": {
-        "my-vendor/project-a": "*"
-    }
-}
-```
-
-Running `composer install` for this `composer.json` will look at
-all of project-a's binaries and install them to `vendor/bin`.
-
-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
-`.bat` files for Windows compatibility. Composer handles installation
-of binaries in a special way when run in a Windows environment:
-
- * A `.bat` file is generated automatically to reference the binary
- * A Unix-style proxy file with the same name as the binary is generated
-   automatically (useful for Cygwin or Git Bash)
-
-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:
-
- 1. Setting the `bin-dir` configuration setting in `composer.json`
- 1. Setting the environment variable `COMPOSER_BIN_DIR`
-
-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 binaries being installed in `scripts/` instead of
-`vendor/bin/`.
-
-You can set `bin-dir` to `./` to put binaries in your project root.

data/helpers/vendor/composer/composer/doc/articles/versions.md

@@ -1,230 +0,0 @@
-<!--
-    tagline: Versions explained.
--->
-
-# Versions and constraints
-
-## Composer Versions vs VCS Versions
-
-Because Composer is heavily geared toward utilizing version control systems
-like git, the term "version" can be a little ambiguous. In the sense of a
-version control system, a "version" is a specific set of files that contain
-specific data. In git terminology, this is a "ref", or a specific commit,
-which may be represented by a branch HEAD or a tag. When you check out that
-version in your VCS -- for example, tag `v1.1` or commit `e35fa0d` --, you're
-asking for a single, known set of files, and you always get the same files back.
-
-In Composer, what's often referred to casually as a version -- that is,
-the string that follows the package name in a require line (e.g., `~1.1` or
-`1.2.*`) -- is actually more specifically a version constraint. Composer
-uses version constraints to figure out which refs in a VCS it should be
-checking out (or simply to verify that a given library is acceptable in
-the case of a statically-maintained library with a `version` specification
-in `composer.json`).
-
-## VCS Tags and Branches
-
-*For the following discussion, let's assume the following sample library
-repository:*
-
-```sh
-~/my-library$ git branch
-v1
-v2
-my-feature
-nother-feature
-
-~/my-library$ git tag
-v1.0
-v1.0.1
-v1.0.2
-v1.1-BETA
-v1.1-RC1
-v1.1-RC2
-v1.1
-v1.1.1
-v2.0-BETA
-v2.0-RC1
-v2.0
-v2.0.1
-v2.0.2
-```
-
-### Tags
-
-Normally, Composer deals with tags (as opposed to branches -- if you don't
-know what this means, read up on
-[version control systems](https://en.wikipedia.org/wiki/Version_control#Common_vocabulary)).
-When you write a version constraint, it may reference a specific tag (e.g.,
-`1.1`) or it may reference a valid range of tags (e.g., `>=1.1 <2.0`, or
-`~4.0`). To resolve these constraints, Composer first asks the VCS to list
-all available tags, then creates an internal list of available versions based
-on these tags. In the above example, composer's internal list includes versions
-`1.0`, `1.0.1`, `1.0.2`, the beta release of `1.1`, the first and second
-release candidates of `1.1`, the final release version `1.1`, etc.... (Note
-that Composer automatically removes the 'v' prefix in the actual tagname to
-get a valid final version number.)
-
-When Composer has a complete list of available versions from your VCS, it then
-finds the highest version that matches all version constraints in your project
-(it's possible that other packages require more specific versions of the
-library than you do, so the version it chooses may not always be the highest
-available version) and it downloads a zip archive of that tag to unpack in the
-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 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.
-
-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.
-
-### Minimum Stability
-
-There's one more thing that will affect which files are checked out of a library's VCS and added to your project: Composer allows you to specify stability constraints to limit which tags are considered valid. In the above example, note that the library released a beta and two release candidates for version `1.1` before the final official release. To receive these versions when running `composer install` or `composer update`, we have to explicitly tell Composer that we are ok with release candidates and beta releases (and alpha releases, if we want those). This can be done using either a project-wide `minimum-stability` value in `composer.json` or using "stability flags" in version constraints. Read more on the [schema page](../04-schema.md#minimum-stability).
-
-## Writing Version Constraints
-
-Now that you have an idea of how Composer sees versions, let's talk about how
-to specify version constraints for your project dependencies.
-
-### Exact Version Constraint
-
-You can specify the exact version of a package. This will tell Composer to
-install this version and this version only. If other dependencies require
-a different version, the solver will ultimately fail and abort any install
-or update procedures.
-
-Example: `1.0.2`
-
-### Version Range
-
-By using comparison operators you can specify ranges of valid versions. Valid
-operators are `>`, `>=`, `<`, `<=`, `!=`.
-
-You can define multiple ranges. Ranges separated by a space (<code>&nbsp;</code>)
-or comma (`,`) will be treated as a **logical AND**. A double pipe (`||`)
-will be treated as a **logical OR**. AND has higher precedence than OR.
-
-> **Note:** Be careful when using unbounded ranges as you might end up
-> unexpectedly installing versions that break backwards compatibility.
-> Consider using the [caret](#caret-version-range-) operator instead for safety.
-
-Examples:
-
-* `>=1.0`
-* `>=1.0 <2.0`
-* `>=1.0 <1.1 || >=1.2`
-
-### Hyphenated Version Range ( - )
-
-Inclusive set of versions. Partial versions on the right include are completed
-with a wildcard. For example `1.0 - 2.0` is equivalent to `>=1.0.0 <2.1` as the
-`2.0` becomes `2.0.*`. On the other hand `1.0.0 - 2.1.0` is equivalent to
-`>=1.0.0 <=2.1.0`.
-
-Example: `1.0 - 2.0`
-
-### Wildcard Version Range (.*)
-
-You can specify a pattern with a `*` wildcard. `1.0.*` is the equivalent of
-`>=1.0 <1.1`.
-
-Example: `1.0.*`
-
-## Next Significant Release Operators
-
-### Tilde Version Range (~)
-
-The `~` operator is best explained by example: `~1.2` is equivalent to
-`>=1.2 <2.0.0`, while `~1.2.3` is equivalent to `>=1.2.3 <1.3.0`. As you can see
-it is mostly useful for projects respecting [semantic
-versioning](https://semver.org/). A common usage would be to mark the minimum
-minor version you depend on, like `~1.2` (which allows anything up to, but not
-including, 2.0). Since in theory there should be no backwards compatibility
-breaks until 2.0, that works well. Another way of looking at it is that using
-`~` specifies a minimum version, but allows the last digit specified to go up.
-
-Example: `~1.2`
-
-> **Note:** Although `2.0-beta.1` is strictly before `2.0`, a version constraint
-> like `~1.2` would not install it. As said above `~1.2` only means the `.2`
-> can change but the `1.` part is fixed.
-
-> **Note:** The `~` operator has an exception on its behavior for the major
-> release number. This means for example that `~1` is the same as `~1.0` as
-> it will not allow the major number to increase trying to keep backwards
-> compatibility.
-
-### Caret Version Range (^)
-
-The `^` operator behaves very similarly but it sticks closer to semantic
-versioning, and will always allow non-breaking updates. For example `^1.2.3`
-is equivalent to `>=1.2.3 <2.0.0` as none of the releases until 2.0 should
-break backwards compatibility. For pre-1.0 versions it also acts with safety
-in mind and treats `^0.3` as `>=0.3.0 <0.4.0`.
-
-This is the recommended operator for maximum interoperability when writing
-library code.
-
-Example: `^1.2.3`
-
-## Stability Constraints
-
-If you are using a constraint that does not explicitly define a stability,
-Composer will default internally to `-dev` or `-stable`, depending on the
-operator(s) used. This happens transparently.
-
-If you wish to explicitly consider only the stable release in the comparison,
-add the suffix `-stable`.
-
-Examples:
-
- Constraint         | Internally
-------------------- | ------------------------
- `1.2.3`            | `=1.2.3.0-stable`
- `>1.2`             | `>1.2.0.0-stable`
- `>=1.2`            | `>=1.2.0.0-dev`
- `>=1.2-stable`     | `>=1.2.0.0-stable`
- `<1.3`             | `<1.3.0.0-dev`
- `<=1.3`            | `<=1.3.0.0-stable`
- `1 - 2`            | `>=1.0.0.0-dev <3.0.0.0-dev`
- `~1.3`             | `>=1.3.0.0-dev <2.0.0.0-dev`
- `1.4.*`            | `>=1.4.0.0-dev <1.5.0.0-dev`
-
-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
-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).
-
-## Summary
-```json
-"require": {
-    "vendor/package": "1.3.2", // exactly 1.3.2
-
-    // >, <, >=, <= | specify upper / lower bounds
-    "vendor/package": ">=1.3.2", // anything above or equal to 1.3.2
-    "vendor/package": "<1.3.2", // anything below 1.3.2
-
-    // * | wildcard
-    "vendor/package": "1.3.*", // >=1.3.0 <1.4.0
-
-    // ~ | allows last digit specified to go up
-    "vendor/package": "~1.3.2", // >=1.3.2 <1.4.0
-    "vendor/package": "~1.3", // >=1.3.0 <2.0.0
-
-    // ^ | doesn't allow breaking changes (major version fixed - following semver)
-    "vendor/package": "^1.3.2", // >=1.3.2 <2.0.0
-    "vendor/package": "^0.3.2", // >=0.3.2 <0.4.0 // except if major version is 0
-}
-```
-
-## Testing Version Constraints
-
-You can test version constraints using [semver.mwl.be](https://semver.mwl.be).
-Fill in a package name and it will autofill the default version constraint
-which Composer would add to your `composer.json` file. You can adjust the
-version constraint and the tool will highlight all releases that match.