Since invalid names will prevent publishing to packagist, they should
be considered publish errors. If people do not plan on submitting their
package to packagist, they can use the --no-check-publish flag to turn
it into a normal warning again.
If the entity loader is disabled on a system, loading files, even from
the local file system, is considered as external to the running php
process, and thus not allowed by the libxml extension. Reading the file
contents and loading the xml as a string is a valid alternative however.
- Move the version api getter to the PluginManager And make it such that it can be mocked, but not pollute the public interface. That means "protected" visibility.
- The plugin api version constant should still be used throughout the code.
- Use different fixtures class names
- Use regex possessive quantifiers for performance
- Use full words for readability
Instead of developing plugins against a single, fixed Plugin API version - `"composer-plugin-api": "1.0.0"`, this change will allow plugin developers to use versions like `"composer-plugin-api": "~1.1"` or `"composer-plugin-api": ">=2.1 <3.0"`, aka actual Composer-compatible constraints.
Only the "1.0", "1.0.0" and "1.0.0" Plugin API versions will be regarded as BC versions, and internally converted to "^1.0"; every other declared version string will be kept as it is.
Because of this new constraint flexibility, plugin version mismatches will be skipped, which means those plugin will NOT be registered to the system. Previously, a mismatch triggered a warning, but plugins were still registered.
This happens on "new PlatformRepository(array($somePackage))".
The parent constructor calls "\Composer\Repository\ArrayRepository::addPackage()",
which, on a brand new repo object, further calls "\Composer\Repository\PlatformRepository::initialize()"
and finally this iterates over a NULLd "$this->overrides", triggering the error.
Kunal Mehta