dependabot-composer 0.90.0 → 0.90.1

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

@@ -1,55 +0,0 @@
-# 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

@@ -1,50 +0,0 @@
-# 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`.
-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:
-
-```json
-{
-    "extra": {
-        "installer-paths": {
-            "sites/example.com/modules/{$name}": ["vendor/package"]
-        }
-    }
-}
-```
-
-Now the package would be installed to your folder location, rather than the default
-composer/installers determined location.
-
-> **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

@@ -1,42 +0,0 @@
-# How do I install Composer programmatically?
-
-As noted on the download page, the installer script contains a
-signature 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_SIGNATURE="$(wget -q -O - https://composer.github.io/installer.sig)"
-php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
-ACTUAL_SIGNATURE="$(php -r "echo hash_file('sha384', 'composer-setup.php');")"
-
-if [ "$EXPECTED_SIGNATURE" != "$ACTUAL_SIGNATURE" ]
-then
-    >&2 echo 'ERROR: Invalid installer signature'
-    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/1b137f8bf6db3e79a38a5bc45324414a6b1f9df2/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

@@ -1,19 +0,0 @@
-# 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

@@ -1,32 +0,0 @@
-# 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

@@ -1,4 +0,0 @@
-# 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

@@ -1,21 +0,0 @@
-# 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

@@ -1,21 +0,0 @@
-# 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

@@ -1,35 +0,0 @@
-# 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

@@ -1,22 +0,0 @@
-# `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

@@ -1,158 +0,0 @@
-{
-    "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"
-            }
-        }
-    }
-}