dependabot-composer 0.118.13 → 0.119.0.beta1

data/helpers/vendor/composer/composer/doc/dev/DefaultPolicy.md

@@ -0,0 +1,55 @@
+# Default Solver Policy
+
+A solver policy defines behaviour variables of the dependency solver. It decides
+which versions are considered newer than others, which packages should be
+preferred over others and whether operations like downgrades or uninstall are
+allowed.
+
+## Selection of preferred Packages
+
+The following describe package pool situations with user requests and the
+resulting order in which the solver will try to install them.
+
+The rules are to be applied in the order of these descriptions.
+
+### Repository priorities
+
+Packages Repo1.Av1, Repo2.Av1
+
+* priority(Repo1) >= priority(Repo2) => (Repo1.Av1, Repo2.Av1)
+* priority(Repo1) <  priority(Repo2) => (Repo2.Av1, Repo1.Av1)
+
+### Package versions
+
+Packages: Av1, Av2, Av3
+
+* Installed: Av2
+
+Request: install A
+
+* (Av3)
+
+### Virtual Packages (provides)
+
+Packages Av1, Bv1
+
+* Av1 provides Xv1
+* Bv1 provides Xv1
+
+Request: install X
+
+* priority(Av1.repo) >= priority(Bv1.repo) => (Av1, Bv1)
+* priority(Av1.repo) <  priority(Bv1.repo) => (Bv1, Av1)
+
+### Package replacements
+
+Packages: Av1, Bv2
+
+* Bv2 replaces Av1
+
+Request: install A
+
+* priority(Av1.repo) >= priority(Bv2.repo) => (Av1, Bv2)
+* priority(Av1.repo) <  priority(Bv2.repo) => (Bv2, Av1)
+
+Bv2 version is ignored, only the replacement version for A matters.

data/helpers/vendor/composer/composer/doc/faqs/how-do-i-install-a-package-to-a-custom-path-for-my-framework.md

@@ -0,0 +1,55 @@
+# How do I install a package to a custom path for my framework?
+
+Each framework may have one or many different required package installation
+paths. Composer can be configured to install packages to a folder other than
+the default `vendor` folder by using
+[composer/installers](https://github.com/composer/installers).
+
+If you are a **package author** and want your package installed to a custom
+directory, simply require `composer/installers` and set the appropriate `type`.
+Specifying the package type, will override the default installer path. 
+This is common if your package is intended for a specific framework such as
+CakePHP, Drupal or WordPress. Here is an example composer.json file for a
+WordPress theme:
+
+```json
+{
+    "name": "you/themename",
+    "type": "wordpress-theme",
+    "require": {
+        "composer/installers": "~1.0"
+    }
+}
+```
+
+Now when your theme is installed with Composer it will be placed into
+`wp-content/themes/themename/` folder. Check the
+[current supported types](https://github.com/composer/installers#current-supported-package-types)
+for your package.
+
+As a **package consumer** you can set or override the install path for a package
+that requires composer/installers by configuring the `installer-paths` extra. A
+useful example would be for a Drupal multisite setup where the package should be
+installed into your sites subdirectory. Here we are overriding the install path
+for a module that uses composer/installers, as well as putting all packages of type
+`drupal-theme` into a themes folder:
+
+```json
+{
+    "extra": {
+        "installer-paths": {
+            "sites/example.com/modules/{$name}": ["vendor/package"],
+            "sites/example.com/themes/{$name}": ["type:drupal-theme"]
+        }
+    }
+}
+```
+
+Now the package would be installed to your folder location, rather than the default
+composer/installers determined location. In addition, `installer-paths` is 
+order-dependent, which means moving a package by name should come before the installer
+path of a `type:*` that matches the same package.
+
+> **Note:** You cannot use this to change the path of any package. This is only
+> applicable to packages that require `composer/installers` and use a custom type
+> that it handles.

data/helpers/vendor/composer/composer/doc/faqs/how-to-install-composer-programmatically.md

@@ -0,0 +1,42 @@
+# How do I install Composer programmatically?
+
+As noted on the download page, the installer script contains a
+checksum which changes when the installer code changes and as such
+it should not be relied upon in the long term.
+
+An alternative is to use this script which only works with UNIX utilities:
+
+```bash
+#!/bin/sh
+
+EXPECTED_CHECKSUM="$(wget -q -O - https://composer.github.io/installer.sig)"
+php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
+ACTUAL_CHECKSUM="$(php -r "echo hash_file('sha384', 'composer-setup.php');")"
+
+if [ "$EXPECTED_CHECKSUM" != "$ACTUAL_CHECKSUM" ]
+then
+    >&2 echo 'ERROR: Invalid installer checksum'
+    rm composer-setup.php
+    exit 1
+fi
+
+php composer-setup.php --quiet
+RESULT=$?
+rm composer-setup.php
+exit $RESULT
+```
+
+The script will exit with 1 in case of failure, or 0 on success, and is quiet
+if no error occurs.
+
+Alternatively, if you want to rely on an exact copy of the installer, you can fetch
+a specific version from GitHub's history. The commit hash should be enough to
+give it uniqueness and authenticity as long as you can trust the GitHub servers.
+For example:
+
+```bash
+wget https://raw.githubusercontent.com/composer/getcomposer.org/76a7060ccb93902cd7576b67264ad91c8a2700e2/web/installer -O - -q | php -- --quiet
+```
+
+You may replace the commit hash by whatever the last commit hash is on
+https://github.com/composer/getcomposer.org/commits/master

data/helpers/vendor/composer/composer/doc/faqs/how-to-install-untrusted-packages-safely.md

@@ -0,0 +1,19 @@
+# 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
+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**.
+
+You can disable plugins and scripts during package installation or updates with the following
+syntax so only Composer's code, and no third party code, will execute:
+
+```sh
+composer install --no-plugins --no-scripts ...
+composer update --no-plugins --no-scripts ...
+```
+
+The `exec` command will always run third party code as the user which runs `composer`.
+
+In some cases, like in CI systems or such where you want to install untrusted dependencies, the
+safest way to do it is to run the above command.

data/helpers/vendor/composer/composer/doc/faqs/should-i-commit-the-dependencies-in-my-vendor-directory.md

@@ -0,0 +1,32 @@
+# Should I commit the dependencies in my vendor directory?
+
+The general recommendation is **no**. The vendor directory (or wherever your
+dependencies are installed) should be added to `.gitignore`/`svn:ignore`/etc.
+
+The best practice is to then have all the developers use Composer to install
+the dependencies. Similarly, the build server, CI, deployment tools etc should
+be adapted to run Composer as part of their project bootstrapping.
+
+While it can be tempting to commit it in some environment, it leads to a few
+problems:
+
+- Large VCS repository size and diffs when you update code.
+- Duplication of the history of all your dependencies in your own VCS.
+- Adding dependencies installed via git to a git repo will show them as
+  submodules. This is problematic because they are not real submodules, and you
+  will run into issues.
+
+If you really feel like you must do this, you have a few options:
+
+1. Limit yourself to installing tagged releases (no dev versions), so that you
+   only get zipped installs, and avoid problems with the git "submodules".
+2. Use --prefer-dist or set `preferred-install` to `dist` in your
+   [config](../04-schema.md#config).
+3. Remove the `.git` directory of every dependency after the installation, then
+   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.
+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.

data/helpers/vendor/composer/composer/doc/faqs/which-version-numbering-system-does-composer-itself-use.md

@@ -0,0 +1,4 @@
+# Which version numbering system does Composer itself use?
+
+Composer uses [Semantic Versioning (aka SemVer)
+2.0.0](https://semver.org/spec/v2.0.0.html).

data/helpers/vendor/composer/composer/doc/faqs/why-are-unbound-version-constraints-a-bad-idea.md

@@ -0,0 +1,21 @@
+# Why are unbound version constraints a bad idea?
+
+A version constraint without an upper bound such as `*`, `>=3.4` or
+`dev-master` will allow updates to any future version of the dependency.
+This includes major versions breaking backward compatibility.
+
+Once a release of your package is tagged, you cannot tweak its dependencies
+anymore in case a dependency breaks BC - you have to do a new release but the
+previous one stays broken.
+
+The only good alternative is to define an upper bound on your constraints,
+which you can increase in a new release after testing that your package is
+compatible with the new major version of your dependency.
+
+For example instead of using `>=3.4` you should use `~3.4` which allows all
+versions up to `3.999` but does not include `4.0` and above. The `^` operator
+works very well with libraries following [semantic versioning](https://semver.org).
+
+**Note:** As a package maintainer, you can make the life of your users easier
+by providing an [alias version](../articles/aliases.md) for your development
+branch to allow it to match bound constraints.

data/helpers/vendor/composer/composer/doc/faqs/why-are-version-constraints-combining-comparisons-and-wildcards-a-bad-idea.md

@@ -0,0 +1,21 @@
+# Why are version constraints combining comparisons and wildcards a bad idea?
+
+This is a fairly common mistake people make, defining version constraints in
+their package requires like `>=2.*` or `>=1.1.*`.
+
+If you think about it and what it really means though, you will quickly
+realize that it does not make much sense. If we decompose `>=2.*`, you
+have two parts:
+
+- `>=2` which says the package should be in version 2.0.0 or above.
+- `2.*` which says the package should be between version 2.0.0 (inclusive)
+  and 3.0.0 (exclusive).
+
+As you see, both rules agree on the fact that the package must be >=2.0.0,
+but it is not possible to determine if when you wrote that you were thinking
+of a package in version 3.0.0 or not. Should it match because you asked for
+`>=2` or should it not match because you asked for a `2.*`?
+
+For this reason, Composer throws an error and says that this is invalid.
+The easy way to fix it is to think about what you really mean, and use only
+one of those rules.

data/helpers/vendor/composer/composer/doc/faqs/why-can't-composer-load-repositories-recursively.md

@@ -0,0 +1,35 @@
+# Why can't Composer load repositories recursively?
+
+You may run into problems when using custom repositories because Composer does
+not load the repositories of your requirements, so you have to redefine those
+repositories in all your `composer.json` files.
+
+Before going into details as to why this is like that, you have to understand
+that the main use of custom VCS & package repositories is to temporarily try
+some things, or use a fork of a project until your pull request is merged, etc.
+You should not use them to keep track of private packages. For that you should
+rather look into [Private Packagist](https://packagist.com) which lets you
+configure all your private packages in one place, and avoids the slow-downs
+associated with inline VCS repositories.
+
+There are three ways the dependency solver could work with custom repositories:
+
+- Fetch the repositories of root package, get all the packages from the defined
+repositories, then resolve requirements. This is the current state and it works well
+except for the limitation of not loading repositories recursively.
+
+- Fetch the repositories of root package, while initializing packages from the
+defined repos, initialize recursively all repos found in those packages, and
+their package's packages, etc, then resolve requirements. It could work, but it
+slows down the initialization a lot since VCS repos can each take a few seconds,
+and it could end up in a completely broken state since many versions of a package
+could define the same packages inside a package repository, but with different
+dist/source. There are many many ways this could go wrong.
+
+- Fetch the repositories of root package, then fetch the repositories of the
+first level dependencies, then fetch the repositories of their dependencies, etc,
+then resolve requirements. This sounds more efficient, but it suffers from the
+same problems as the second solution, because loading the repositories of the
+dependencies is not as easy as it sounds. You need to load all the repos of all
+the potential matches for a requirement, which again might have conflicting
+package definitions.

data/helpers/vendor/composer/composer/doc/fixtures/fixtures.md

@@ -0,0 +1,22 @@
+# `Composer` type repository fixtures
+
+This directory contains some examples of what `composer` type repositories can
+look like. They serve as illustrating examples accompanying the docs, but can
+also be used as (initial) fixtures for tests.
+
+* `repo-composer-plain` is a simple, plain `packages.json` file
+* `repo-composer-with-includes` uses the `includes` mechanism
+* `repo-composer-with-providers` uses the `providers` mechanism
+
+## Sample Packages used in these fixtures
+
+All these repositories contain the following packages.
+
+* `foo/bar` versions 1.0.0, 1.0.1 and 1.1.0; dev-default and 1.0.x-dev branches.
+   On dev-default and in 1.1.0, `bar/baz` ~1.0 is required.
+* `qux/quux` only has a dev-default branch. It `replace`s `gar/nix`.
+* `gar/nix` has a 1.0.0 version and a dev-default branch. It is being replaced
+   by `qux/quux`.
+* `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.
+

data/helpers/vendor/composer/composer/doc/fixtures/repo-composer-plain/packages.json

@@ -0,0 +1,158 @@
+{
+    "packages": {
+        "bar/baz": {
+            "1.0.0": {
+                "name": "bar/baz",
+                "version": "1.0.0",
+                "version_normalized": "1.0.0.0",
+                "source": {
+                    "type": "hg",
+                    "url": "http://some.where/over/the/rainbow/",
+                    "reference": "35810817c14d"
+                },
+                "time": "2014-10-13 12:04:55",
+                "type": "library"
+            },
+            "1.0.x-dev": {
+                "name": "bar/baz",
+                "version": "1.0.x-dev",
+                "version_normalized": "1.0.9999999.9999999-dev",
+                "source": {
+                    "type": "hg",
+                    "url": "http://some.where/over/the/rainbow/",
+                    "reference": "ffff9aae6ed5"
+                },
+                "time": "2014-10-13 12:05:37",
+                "type": "library"
+            },
+            "dev-default": {
+                "name": "bar/baz",
+                "version": "dev-default",
+                "version_normalized": "9999999-dev",
+                "source": {
+                    "type": "hg",
+                    "url": "http://some.where/over/the/rainbow/",
+                    "reference": "f317e556f2e2"
+                },
+                "time": "2014-10-13 12:06:45",
+                "type": "library",
+                "extra": {
+                    "branch-alias": {
+                        "dev-default": "1.1.x-dev"
+                    }
+                }
+            }
+        },
+        "foo/bar": {
+            "1.0.0": {
+                "name": "foo/bar",
+                "version": "1.0.0",
+                "version_normalized": "1.0.0.0",
+                "source": {
+                    "type": "hg",
+                    "url": "http://some.where/over/the/rainbow/",
+                    "reference": "249dec95a52a"
+                },
+                "time": "2014-10-11 15:42:00",
+                "type": "library"
+            },
+            "1.0.1": {
+                "name": "foo/bar",
+                "version": "1.0.1",
+                "version_normalized": "1.0.1.0",
+                "source": {
+                    "type": "hg",
+                    "url": "http://some.where/over/the/rainbow/",
+                    "reference": "21e3328295d4"
+                },
+                "time": "2014-10-11 15:45:56",
+                "type": "library"
+            },
+            "1.0.x-dev": {
+                "name": "foo/bar",
+                "version": "1.0.x-dev",
+                "version_normalized": "1.0.9999999.9999999-dev",
+                "source": {
+                    "type": "hg",
+                    "url": "http://some.where/over/the/rainbow/",
+                    "reference": "14dc17c8e860"
+                },
+                "time": "2014-10-11 15:45:59",
+                "type": "library"
+            },
+            "1.1.0": {
+                "name": "foo/bar",
+                "version": "1.1.0",
+                "version_normalized": "1.1.0.0",
+                "source": {
+                    "type": "hg",
+                    "url": "http://some.where/over/the/rainbow/",
+                    "reference": "d2fa3e69ad5b"
+                },
+                "require": {
+                    "bar/baz": "~1.0"
+                },
+                "time": "2014-10-11 15:43:16",
+                "type": "library"
+            },
+            "dev-default": {
+                "name": "foo/bar",
+                "version": "dev-default",
+                "version_normalized": "9999999-dev",
+                "source": {
+                    "type": "hg",
+                    "url": "http://some.where/over/the/rainbow/",
+                    "reference": "8e5a5c224336"
+                },
+                "require": {
+                    "bar/baz": "~1.0"
+                },
+                "time": "2014-10-11 15:43:18",
+                "type": "library"
+            }
+        },
+        "gar/nix": {
+            "1.0.0": {
+                "name": "gar/nix",
+                "version": "1.0.0",
+                "version_normalized": "1.0.0.0",
+                "source": {
+                    "type": "hg",
+                    "url": "http://some.where/over/the/rainbow/",
+                    "reference": "44977145d64e"
+                },
+                "time": "2014-10-13 12:03:33",
+                "type": "library"
+            },
+            "dev-default": {
+                "name": "gar/nix",
+                "version": "dev-default",
+                "version_normalized": "9999999-dev",
+                "source": {
+                    "type": "hg",
+                    "url": "http://some.where/over/the/rainbow/",
+                    "reference": "51cca95a31c2"
+                },
+                "time": "2014-10-13 12:03:35",
+                "type": "library"
+            }
+        },
+        "qux/quux": {
+            "dev-default": {
+                "name": "qux/quux",
+                "version": "dev-default",
+                "version_normalized": "9999999-dev",
+                "source": {
+                    "type": "hg",
+                    "url": "http://some.where/over/the/rainbow/",
+                    "reference": "4a10a567baa5"
+                },
+                "replace": {
+                    "gar/nix": "1.0.*"
+                },
+                "time": "2014-10-11 15:48:15",
+                "type": "library"
+            }
+        }
+    }
+}