this is not as good as phpstan/phpstan-src#769 (e.g. array_key_first()/array_key_last() aren't covered by this, nor is array_rand()) but it does eliminate the most infuriating cases where this usually crops up.
this could happen if a plugin declared a permission already declared by another plugin, and then declared a different default for it (e.g. true instead of op).
loadPlugins() is now the preferred option, since it does all the proper checks.
In addition, the server now acknowledges that loading a single plugin may cause multiple plugins to be loaded, so returning only a single Plugin is not representative of what's actually happening.
loadPlugins() is now a superior option to loadPlugin(), since it enforces dependency checks and also supports automatic loading of plugins when new loaders are installed.
it's not worth this turning into compatibility baggage just so that we can parse plugin_list.yml, especially when we have new ways to handle data parsing coming in the pipeline.
For something as small as plugin_list.yml, it's easier (and in this case better too) to just validate it manually (respect/validation was anyway too strict considering it's YAML we're dealing with).
for some reason we were reading and parsing the plugin.yml at least twice for every plugin loaded.
We were repeating work already done by the initial loadPlugins() triage (discovering correct loader, loading plugin.yml from disk, parsing plugin.yml, validating plugin.yml) every time loadPlugin() was called with that plugin.
this could lead to harmful results, e.g. if a developer typo'd while writing the plugin.yml, an admin-only command could become accessible to everyone, since commands are by default accessible by everyone.
this makes translation usage much more statically analysable.
The only places this isn't used are:
- places that prefix translations with colours (those are still a problem)
- places where server/client translations don't match (e.g. gameMode.changed accepts different parameters in vanilla than in PM)
it's better to just implement this for stuff where there's explicitly designated aliases, otherwise we could end up with unexpected BC breaks (e.g. hardcoding POSTWORLD in plugin.yml would suddenly break if the core enum was changed, even though it remained valid).
* Allow plugins to use PSR-4 namespace mapping
this is a reduced implementation which serves the 99% use case without being horribly breakable.
Plugins may now specify a `src-namespace-prefix`, which should be set to the namespace of the classes in `src`.
If the old system is used, `src-namespace-prefix` can be omitted, or set to an empty string.
Examples:
- If `src-namespace-prefix` is `dktapps\test`, `dktapps\test\Main` will be searched for in `src/Main.php`, instead of `src/dktapps/test/Main.php`.
* Migrate TesterPlugin to PSR-4
Plugin is the interface by which the server core interacts with plugins, so it should be limited only to the stuff that the server actually uses.
These methods are still provided by PluginBase, so in 99.9% of cases there will be no BC break.
