This only removes the credentials if they are managed by composer auth.json or equivalent, if the credentials were present in the package URL to begin with they might remain
Refs #8293Fixes#3644Closes#3608
Particularly the test
tests/Composer/Test/Fixtures/installer/partial-update-downgrades-non-whitelisted-unstable.test
is interesting because it verifies that an older version will be
installed on update if the new one is only present in the installed repo
or vendor dir. This was the cause of a lot of weird edge cases and
unreliable update behavior in Composer v1
As a result some lock file packages are no longer in the pool, so the
former installed map, now present map cannot use package ids anymore
Need to revisit some more code later to simplify this, todo notes left
Ensures packages get loaded from locked repo correctly. We may not want
to support this particular use-case at all, but for now it fixes the
existing test, so we may want to revisit this later.
When the `lock` option is set to false, composer will not write a
`composer.lock` file to disk. This signals that the package is meant
to be developed with unlocked and always updated dependencies. At the
moment, both `install` and `update` are allowed to install the
dependencies for such a package. If #6822 is implemented, only `update`
should be used for packages without a lockfile.
https://github.com/composer/composer/issues/8354
https://www.php.net/strpos has the signature
`strpos ( string $haystack , mixed $needle [, int $offset = 0 ] ) : int`
(The needle is usually the constant)
`strpos('/', $suggestion)` would only be `false` for `''` and `'/'`
So the existing check would just not suggest **anything** that was
already installed (from pecl, built-in, or composer).
The intent seems to be to not suggest non-vendored php packages
that were already installed. (b20cc22ebb)