Plugin loading (#855)
* add ability to load plugins by class names
- Plugins need to implement `__invoke(PluginFacade $psalm):void` method
- Plugins are enabled by adding `<pluginClass
class="Qualified\Class\Name"/>`
- `PluginFacade` provides a single point of contact with Psalm, so that
plugins cannot become coupled to Psalm internals
* added `psalm-plugin` cli tool to manage plugins
Available commands:
`psalm-plugin list` - lists available and enabled plugins
`psalm-plugin enable 'Plugin\Class\Name'` - enables plugin (modifies `psalm.xml`)
`psalm-plugin disable 'Plugin\Class\Name'` - disables plugin (modifies `psalm.xml`)
Plugin installation:
`composer install plugin-vendor/plugin-package-name`
Plugin authoring:
Plugins are identified by package `type` field, which should contain
`psalm-plugin` string.
`extra.pluginClass` should refer to the name of the class implementing
`__invoke(PluginFacade $psalm):void` function
Todo:
- better config file search
- better output for `psalm-plugin`
- better formatting for modified xml file
- composer skeleton project for plugins
- ability to refer to plugins by package name (cli only)
- composer plugin to (optionally) enable plugin upon installation
- documentation on plugin installation and authoring
- interfaces for plugin dependencies
- interface for plugin entry point
- migration path for legacy plugins
* documented previously undocumented plugin methods
* split legacy plugin registration into a wrapper class
also added `PluginApi` namespace and `RegistrationInterface`
* reuse psalm's config search algorithm
* enable/disable plugins by composer package name
* allow specifying alternative config file name
* whitelist PluginApi namespace
three times, but well, it works now
* interface for plugin entry points
* psalm-plugin as a symfony console app
* fixed errors found by psalm
* suppressed false positive UnusedMethods
* cs fix
* better psalm-plugin output
* don't leave empty `plugins` node to avoid old schema violation
* removed junk file that shouldn't be there
* cs fix
* fixed phpunit failure (constant redefinition)
* work around missing docblock in on symfony console
* php 7.0 compatibility
* allow `pluginClass` child elements as plugin configuration
* decouple console commands from undelying implementation
- introduce PluginListFactory
- add `PluginList::enable(string $class)` and `PluginList::disable(string $class)`
* PluginList tests
* ComposerLock test
* droppped debugging statement
* added part of console command tests
* added tests for EnableCommand
* added DisableCommand tests
* ignore unused args
* ConfigFile test
* disable travis cache in attempt to fix builds
* nah, that didn't work
* update for upstream changes
* rebase fixes
* namespaced `extra` entry for entry point
* s/PluginFacade/PluginRegistrationSocket/g
* Added $config parameter to PluginEntryPointInterface::__invoke()
* cs fixes
* entry point interface php7.0 compatibility
* cleaned up old cruft
- dropped todos I'm not going to pursues
- locked entry point to be a class implementing entry point interface
* fixed legacy plugins docs
* Added RegistrationInterface::registerHooksFromClass()
It mimics the way old plugins were registered in Psalm\Config, so
handler classes extending Psalm\Plugin should be fully compatible with
it.
Since Psalm\Plugin-style plugin registration was moved to
RegistrationSocket, LegacyPlugin now only load file-based plugins, so it
was renamed to FileBasedPluginAdapter.
* Converted EchoChecker plugin to composer-based format
- Its subfolder is registered as a local composer package in the root
composer.json, so it's directly installable with
```
composer require psalm/echo-checker-plugin
```
- Migration is trivial: drop the plugin into a separate folder, then add
simple composer.json and the entry point class.
* Updated docs
* Don't reject hook handlers that inherit handling methods
* strip void return type in stub file
2018-11-11 05:23:36 +01:00
|
|
|
<?php
|
2021-12-15 04:58:32 +01:00
|
|
|
|
2019-05-10 00:58:30 +02:00
|
|
|
namespace Psalm\Tests\Config;
|
Plugin loading (#855)
* add ability to load plugins by class names
- Plugins need to implement `__invoke(PluginFacade $psalm):void` method
- Plugins are enabled by adding `<pluginClass
class="Qualified\Class\Name"/>`
- `PluginFacade` provides a single point of contact with Psalm, so that
plugins cannot become coupled to Psalm internals
* added `psalm-plugin` cli tool to manage plugins
Available commands:
`psalm-plugin list` - lists available and enabled plugins
`psalm-plugin enable 'Plugin\Class\Name'` - enables plugin (modifies `psalm.xml`)
`psalm-plugin disable 'Plugin\Class\Name'` - disables plugin (modifies `psalm.xml`)
Plugin installation:
`composer install plugin-vendor/plugin-package-name`
Plugin authoring:
Plugins are identified by package `type` field, which should contain
`psalm-plugin` string.
`extra.pluginClass` should refer to the name of the class implementing
`__invoke(PluginFacade $psalm):void` function
Todo:
- better config file search
- better output for `psalm-plugin`
- better formatting for modified xml file
- composer skeleton project for plugins
- ability to refer to plugins by package name (cli only)
- composer plugin to (optionally) enable plugin upon installation
- documentation on plugin installation and authoring
- interfaces for plugin dependencies
- interface for plugin entry point
- migration path for legacy plugins
* documented previously undocumented plugin methods
* split legacy plugin registration into a wrapper class
also added `PluginApi` namespace and `RegistrationInterface`
* reuse psalm's config search algorithm
* enable/disable plugins by composer package name
* allow specifying alternative config file name
* whitelist PluginApi namespace
three times, but well, it works now
* interface for plugin entry points
* psalm-plugin as a symfony console app
* fixed errors found by psalm
* suppressed false positive UnusedMethods
* cs fix
* better psalm-plugin output
* don't leave empty `plugins` node to avoid old schema violation
* removed junk file that shouldn't be there
* cs fix
* fixed phpunit failure (constant redefinition)
* work around missing docblock in on symfony console
* php 7.0 compatibility
* allow `pluginClass` child elements as plugin configuration
* decouple console commands from undelying implementation
- introduce PluginListFactory
- add `PluginList::enable(string $class)` and `PluginList::disable(string $class)`
* PluginList tests
* ComposerLock test
* droppped debugging statement
* added part of console command tests
* added tests for EnableCommand
* added DisableCommand tests
* ignore unused args
* ConfigFile test
* disable travis cache in attempt to fix builds
* nah, that didn't work
* update for upstream changes
* rebase fixes
* namespaced `extra` entry for entry point
* s/PluginFacade/PluginRegistrationSocket/g
* Added $config parameter to PluginEntryPointInterface::__invoke()
* cs fixes
* entry point interface php7.0 compatibility
* cleaned up old cruft
- dropped todos I'm not going to pursues
- locked entry point to be a class implementing entry point interface
* fixed legacy plugins docs
* Added RegistrationInterface::registerHooksFromClass()
It mimics the way old plugins were registered in Psalm\Config, so
handler classes extending Psalm\Plugin should be fully compatible with
it.
Since Psalm\Plugin-style plugin registration was moved to
RegistrationSocket, LegacyPlugin now only load file-based plugins, so it
was renamed to FileBasedPluginAdapter.
* Converted EchoChecker plugin to composer-based format
- Its subfolder is registered as a local composer package in the root
composer.json, so it's directly installable with
```
composer require psalm/echo-checker-plugin
```
- Migration is trivial: drop the plugin into a separate folder, then add
simple composer.json and the entry point class.
* Updated docs
* Don't reject hook handlers that inherit handling methods
* strip void return type in stub file
2018-11-11 05:23:36 +01:00
|
|
|
|
2021-12-03 21:40:18 +01:00
|
|
|
use InvalidArgumentException;
|
2020-08-25 00:02:39 +02:00
|
|
|
use Prophecy\PhpUnit\ProphecyTrait;
|
Plugin loading (#855)
* add ability to load plugins by class names
- Plugins need to implement `__invoke(PluginFacade $psalm):void` method
- Plugins are enabled by adding `<pluginClass
class="Qualified\Class\Name"/>`
- `PluginFacade` provides a single point of contact with Psalm, so that
plugins cannot become coupled to Psalm internals
* added `psalm-plugin` cli tool to manage plugins
Available commands:
`psalm-plugin list` - lists available and enabled plugins
`psalm-plugin enable 'Plugin\Class\Name'` - enables plugin (modifies `psalm.xml`)
`psalm-plugin disable 'Plugin\Class\Name'` - disables plugin (modifies `psalm.xml`)
Plugin installation:
`composer install plugin-vendor/plugin-package-name`
Plugin authoring:
Plugins are identified by package `type` field, which should contain
`psalm-plugin` string.
`extra.pluginClass` should refer to the name of the class implementing
`__invoke(PluginFacade $psalm):void` function
Todo:
- better config file search
- better output for `psalm-plugin`
- better formatting for modified xml file
- composer skeleton project for plugins
- ability to refer to plugins by package name (cli only)
- composer plugin to (optionally) enable plugin upon installation
- documentation on plugin installation and authoring
- interfaces for plugin dependencies
- interface for plugin entry point
- migration path for legacy plugins
* documented previously undocumented plugin methods
* split legacy plugin registration into a wrapper class
also added `PluginApi` namespace and `RegistrationInterface`
* reuse psalm's config search algorithm
* enable/disable plugins by composer package name
* allow specifying alternative config file name
* whitelist PluginApi namespace
three times, but well, it works now
* interface for plugin entry points
* psalm-plugin as a symfony console app
* fixed errors found by psalm
* suppressed false positive UnusedMethods
* cs fix
* better psalm-plugin output
* don't leave empty `plugins` node to avoid old schema violation
* removed junk file that shouldn't be there
* cs fix
* fixed phpunit failure (constant redefinition)
* work around missing docblock in on symfony console
* php 7.0 compatibility
* allow `pluginClass` child elements as plugin configuration
* decouple console commands from undelying implementation
- introduce PluginListFactory
- add `PluginList::enable(string $class)` and `PluginList::disable(string $class)`
* PluginList tests
* ComposerLock test
* droppped debugging statement
* added part of console command tests
* added tests for EnableCommand
* added DisableCommand tests
* ignore unused args
* ConfigFile test
* disable travis cache in attempt to fix builds
* nah, that didn't work
* update for upstream changes
* rebase fixes
* namespaced `extra` entry for entry point
* s/PluginFacade/PluginRegistrationSocket/g
* Added $config parameter to PluginEntryPointInterface::__invoke()
* cs fixes
* entry point interface php7.0 compatibility
* cleaned up old cruft
- dropped todos I'm not going to pursues
- locked entry point to be a class implementing entry point interface
* fixed legacy plugins docs
* Added RegistrationInterface::registerHooksFromClass()
It mimics the way old plugins were registered in Psalm\Config, so
handler classes extending Psalm\Plugin should be fully compatible with
it.
Since Psalm\Plugin-style plugin registration was moved to
RegistrationSocket, LegacyPlugin now only load file-based plugins, so it
was renamed to FileBasedPluginAdapter.
* Converted EchoChecker plugin to composer-based format
- Its subfolder is registered as a local composer package in the root
composer.json, so it's directly installable with
```
composer require psalm/echo-checker-plugin
```
- Migration is trivial: drop the plugin into a separate folder, then add
simple composer.json and the entry point class.
* Updated docs
* Don't reject hook handlers that inherit handling methods
* strip void return type in stub file
2018-11-11 05:23:36 +01:00
|
|
|
use Prophecy\Prophecy\ObjectProphecy;
|
|
|
|
use Psalm\Config;
|
2018-11-18 18:41:47 +01:00
|
|
|
use Psalm\Internal\PluginManager\ComposerLock;
|
|
|
|
use Psalm\Internal\PluginManager\ConfigFile;
|
|
|
|
use Psalm\Internal\PluginManager\PluginList;
|
2020-08-23 16:32:07 +02:00
|
|
|
use Psalm\Internal\RuntimeCaches;
|
2021-12-03 20:11:20 +01:00
|
|
|
use Psalm\Tests\TestCase;
|
Plugin loading (#855)
* add ability to load plugins by class names
- Plugins need to implement `__invoke(PluginFacade $psalm):void` method
- Plugins are enabled by adding `<pluginClass
class="Qualified\Class\Name"/>`
- `PluginFacade` provides a single point of contact with Psalm, so that
plugins cannot become coupled to Psalm internals
* added `psalm-plugin` cli tool to manage plugins
Available commands:
`psalm-plugin list` - lists available and enabled plugins
`psalm-plugin enable 'Plugin\Class\Name'` - enables plugin (modifies `psalm.xml`)
`psalm-plugin disable 'Plugin\Class\Name'` - disables plugin (modifies `psalm.xml`)
Plugin installation:
`composer install plugin-vendor/plugin-package-name`
Plugin authoring:
Plugins are identified by package `type` field, which should contain
`psalm-plugin` string.
`extra.pluginClass` should refer to the name of the class implementing
`__invoke(PluginFacade $psalm):void` function
Todo:
- better config file search
- better output for `psalm-plugin`
- better formatting for modified xml file
- composer skeleton project for plugins
- ability to refer to plugins by package name (cli only)
- composer plugin to (optionally) enable plugin upon installation
- documentation on plugin installation and authoring
- interfaces for plugin dependencies
- interface for plugin entry point
- migration path for legacy plugins
* documented previously undocumented plugin methods
* split legacy plugin registration into a wrapper class
also added `PluginApi` namespace and `RegistrationInterface`
* reuse psalm's config search algorithm
* enable/disable plugins by composer package name
* allow specifying alternative config file name
* whitelist PluginApi namespace
three times, but well, it works now
* interface for plugin entry points
* psalm-plugin as a symfony console app
* fixed errors found by psalm
* suppressed false positive UnusedMethods
* cs fix
* better psalm-plugin output
* don't leave empty `plugins` node to avoid old schema violation
* removed junk file that shouldn't be there
* cs fix
* fixed phpunit failure (constant redefinition)
* work around missing docblock in on symfony console
* php 7.0 compatibility
* allow `pluginClass` child elements as plugin configuration
* decouple console commands from undelying implementation
- introduce PluginListFactory
- add `PluginList::enable(string $class)` and `PluginList::disable(string $class)`
* PluginList tests
* ComposerLock test
* droppped debugging statement
* added part of console command tests
* added tests for EnableCommand
* added DisableCommand tests
* ignore unused args
* ConfigFile test
* disable travis cache in attempt to fix builds
* nah, that didn't work
* update for upstream changes
* rebase fixes
* namespaced `extra` entry for entry point
* s/PluginFacade/PluginRegistrationSocket/g
* Added $config parameter to PluginEntryPointInterface::__invoke()
* cs fixes
* entry point interface php7.0 compatibility
* cleaned up old cruft
- dropped todos I'm not going to pursues
- locked entry point to be a class implementing entry point interface
* fixed legacy plugins docs
* Added RegistrationInterface::registerHooksFromClass()
It mimics the way old plugins were registered in Psalm\Config, so
handler classes extending Psalm\Plugin should be fully compatible with
it.
Since Psalm\Plugin-style plugin registration was moved to
RegistrationSocket, LegacyPlugin now only load file-based plugins, so it
was renamed to FileBasedPluginAdapter.
* Converted EchoChecker plugin to composer-based format
- Its subfolder is registered as a local composer package in the root
composer.json, so it's directly installable with
```
composer require psalm/echo-checker-plugin
```
- Migration is trivial: drop the plugin into a separate folder, then add
simple composer.json and the entry point class.
* Updated docs
* Don't reject hook handlers that inherit handling methods
* strip void return type in stub file
2018-11-11 05:23:36 +01:00
|
|
|
|
|
|
|
/** @group PluginManager */
|
2021-12-03 20:11:20 +01:00
|
|
|
class PluginListTest extends TestCase
|
Plugin loading (#855)
* add ability to load plugins by class names
- Plugins need to implement `__invoke(PluginFacade $psalm):void` method
- Plugins are enabled by adding `<pluginClass
class="Qualified\Class\Name"/>`
- `PluginFacade` provides a single point of contact with Psalm, so that
plugins cannot become coupled to Psalm internals
* added `psalm-plugin` cli tool to manage plugins
Available commands:
`psalm-plugin list` - lists available and enabled plugins
`psalm-plugin enable 'Plugin\Class\Name'` - enables plugin (modifies `psalm.xml`)
`psalm-plugin disable 'Plugin\Class\Name'` - disables plugin (modifies `psalm.xml`)
Plugin installation:
`composer install plugin-vendor/plugin-package-name`
Plugin authoring:
Plugins are identified by package `type` field, which should contain
`psalm-plugin` string.
`extra.pluginClass` should refer to the name of the class implementing
`__invoke(PluginFacade $psalm):void` function
Todo:
- better config file search
- better output for `psalm-plugin`
- better formatting for modified xml file
- composer skeleton project for plugins
- ability to refer to plugins by package name (cli only)
- composer plugin to (optionally) enable plugin upon installation
- documentation on plugin installation and authoring
- interfaces for plugin dependencies
- interface for plugin entry point
- migration path for legacy plugins
* documented previously undocumented plugin methods
* split legacy plugin registration into a wrapper class
also added `PluginApi` namespace and `RegistrationInterface`
* reuse psalm's config search algorithm
* enable/disable plugins by composer package name
* allow specifying alternative config file name
* whitelist PluginApi namespace
three times, but well, it works now
* interface for plugin entry points
* psalm-plugin as a symfony console app
* fixed errors found by psalm
* suppressed false positive UnusedMethods
* cs fix
* better psalm-plugin output
* don't leave empty `plugins` node to avoid old schema violation
* removed junk file that shouldn't be there
* cs fix
* fixed phpunit failure (constant redefinition)
* work around missing docblock in on symfony console
* php 7.0 compatibility
* allow `pluginClass` child elements as plugin configuration
* decouple console commands from undelying implementation
- introduce PluginListFactory
- add `PluginList::enable(string $class)` and `PluginList::disable(string $class)`
* PluginList tests
* ComposerLock test
* droppped debugging statement
* added part of console command tests
* added tests for EnableCommand
* added DisableCommand tests
* ignore unused args
* ConfigFile test
* disable travis cache in attempt to fix builds
* nah, that didn't work
* update for upstream changes
* rebase fixes
* namespaced `extra` entry for entry point
* s/PluginFacade/PluginRegistrationSocket/g
* Added $config parameter to PluginEntryPointInterface::__invoke()
* cs fixes
* entry point interface php7.0 compatibility
* cleaned up old cruft
- dropped todos I'm not going to pursues
- locked entry point to be a class implementing entry point interface
* fixed legacy plugins docs
* Added RegistrationInterface::registerHooksFromClass()
It mimics the way old plugins were registered in Psalm\Config, so
handler classes extending Psalm\Plugin should be fully compatible with
it.
Since Psalm\Plugin-style plugin registration was moved to
RegistrationSocket, LegacyPlugin now only load file-based plugins, so it
was renamed to FileBasedPluginAdapter.
* Converted EchoChecker plugin to composer-based format
- Its subfolder is registered as a local composer package in the root
composer.json, so it's directly installable with
```
composer require psalm/echo-checker-plugin
```
- Migration is trivial: drop the plugin into a separate folder, then add
simple composer.json and the entry point class.
* Updated docs
* Don't reject hook handlers that inherit handling methods
* strip void return type in stub file
2018-11-11 05:23:36 +01:00
|
|
|
{
|
2020-08-25 00:02:39 +02:00
|
|
|
use ProphecyTrait;
|
|
|
|
|
2019-03-01 14:45:18 +01:00
|
|
|
/** @var ObjectProphecy<ConfigFile> */
|
Plugin loading (#855)
* add ability to load plugins by class names
- Plugins need to implement `__invoke(PluginFacade $psalm):void` method
- Plugins are enabled by adding `<pluginClass
class="Qualified\Class\Name"/>`
- `PluginFacade` provides a single point of contact with Psalm, so that
plugins cannot become coupled to Psalm internals
* added `psalm-plugin` cli tool to manage plugins
Available commands:
`psalm-plugin list` - lists available and enabled plugins
`psalm-plugin enable 'Plugin\Class\Name'` - enables plugin (modifies `psalm.xml`)
`psalm-plugin disable 'Plugin\Class\Name'` - disables plugin (modifies `psalm.xml`)
Plugin installation:
`composer install plugin-vendor/plugin-package-name`
Plugin authoring:
Plugins are identified by package `type` field, which should contain
`psalm-plugin` string.
`extra.pluginClass` should refer to the name of the class implementing
`__invoke(PluginFacade $psalm):void` function
Todo:
- better config file search
- better output for `psalm-plugin`
- better formatting for modified xml file
- composer skeleton project for plugins
- ability to refer to plugins by package name (cli only)
- composer plugin to (optionally) enable plugin upon installation
- documentation on plugin installation and authoring
- interfaces for plugin dependencies
- interface for plugin entry point
- migration path for legacy plugins
* documented previously undocumented plugin methods
* split legacy plugin registration into a wrapper class
also added `PluginApi` namespace and `RegistrationInterface`
* reuse psalm's config search algorithm
* enable/disable plugins by composer package name
* allow specifying alternative config file name
* whitelist PluginApi namespace
three times, but well, it works now
* interface for plugin entry points
* psalm-plugin as a symfony console app
* fixed errors found by psalm
* suppressed false positive UnusedMethods
* cs fix
* better psalm-plugin output
* don't leave empty `plugins` node to avoid old schema violation
* removed junk file that shouldn't be there
* cs fix
* fixed phpunit failure (constant redefinition)
* work around missing docblock in on symfony console
* php 7.0 compatibility
* allow `pluginClass` child elements as plugin configuration
* decouple console commands from undelying implementation
- introduce PluginListFactory
- add `PluginList::enable(string $class)` and `PluginList::disable(string $class)`
* PluginList tests
* ComposerLock test
* droppped debugging statement
* added part of console command tests
* added tests for EnableCommand
* added DisableCommand tests
* ignore unused args
* ConfigFile test
* disable travis cache in attempt to fix builds
* nah, that didn't work
* update for upstream changes
* rebase fixes
* namespaced `extra` entry for entry point
* s/PluginFacade/PluginRegistrationSocket/g
* Added $config parameter to PluginEntryPointInterface::__invoke()
* cs fixes
* entry point interface php7.0 compatibility
* cleaned up old cruft
- dropped todos I'm not going to pursues
- locked entry point to be a class implementing entry point interface
* fixed legacy plugins docs
* Added RegistrationInterface::registerHooksFromClass()
It mimics the way old plugins were registered in Psalm\Config, so
handler classes extending Psalm\Plugin should be fully compatible with
it.
Since Psalm\Plugin-style plugin registration was moved to
RegistrationSocket, LegacyPlugin now only load file-based plugins, so it
was renamed to FileBasedPluginAdapter.
* Converted EchoChecker plugin to composer-based format
- Its subfolder is registered as a local composer package in the root
composer.json, so it's directly installable with
```
composer require psalm/echo-checker-plugin
```
- Migration is trivial: drop the plugin into a separate folder, then add
simple composer.json and the entry point class.
* Updated docs
* Don't reject hook handlers that inherit handling methods
* strip void return type in stub file
2018-11-11 05:23:36 +01:00
|
|
|
private $config_file;
|
2019-03-01 14:45:18 +01:00
|
|
|
|
|
|
|
/** @var ObjectProphecy<Config> */
|
Plugin loading (#855)
* add ability to load plugins by class names
- Plugins need to implement `__invoke(PluginFacade $psalm):void` method
- Plugins are enabled by adding `<pluginClass
class="Qualified\Class\Name"/>`
- `PluginFacade` provides a single point of contact with Psalm, so that
plugins cannot become coupled to Psalm internals
* added `psalm-plugin` cli tool to manage plugins
Available commands:
`psalm-plugin list` - lists available and enabled plugins
`psalm-plugin enable 'Plugin\Class\Name'` - enables plugin (modifies `psalm.xml`)
`psalm-plugin disable 'Plugin\Class\Name'` - disables plugin (modifies `psalm.xml`)
Plugin installation:
`composer install plugin-vendor/plugin-package-name`
Plugin authoring:
Plugins are identified by package `type` field, which should contain
`psalm-plugin` string.
`extra.pluginClass` should refer to the name of the class implementing
`__invoke(PluginFacade $psalm):void` function
Todo:
- better config file search
- better output for `psalm-plugin`
- better formatting for modified xml file
- composer skeleton project for plugins
- ability to refer to plugins by package name (cli only)
- composer plugin to (optionally) enable plugin upon installation
- documentation on plugin installation and authoring
- interfaces for plugin dependencies
- interface for plugin entry point
- migration path for legacy plugins
* documented previously undocumented plugin methods
* split legacy plugin registration into a wrapper class
also added `PluginApi` namespace and `RegistrationInterface`
* reuse psalm's config search algorithm
* enable/disable plugins by composer package name
* allow specifying alternative config file name
* whitelist PluginApi namespace
three times, but well, it works now
* interface for plugin entry points
* psalm-plugin as a symfony console app
* fixed errors found by psalm
* suppressed false positive UnusedMethods
* cs fix
* better psalm-plugin output
* don't leave empty `plugins` node to avoid old schema violation
* removed junk file that shouldn't be there
* cs fix
* fixed phpunit failure (constant redefinition)
* work around missing docblock in on symfony console
* php 7.0 compatibility
* allow `pluginClass` child elements as plugin configuration
* decouple console commands from undelying implementation
- introduce PluginListFactory
- add `PluginList::enable(string $class)` and `PluginList::disable(string $class)`
* PluginList tests
* ComposerLock test
* droppped debugging statement
* added part of console command tests
* added tests for EnableCommand
* added DisableCommand tests
* ignore unused args
* ConfigFile test
* disable travis cache in attempt to fix builds
* nah, that didn't work
* update for upstream changes
* rebase fixes
* namespaced `extra` entry for entry point
* s/PluginFacade/PluginRegistrationSocket/g
* Added $config parameter to PluginEntryPointInterface::__invoke()
* cs fixes
* entry point interface php7.0 compatibility
* cleaned up old cruft
- dropped todos I'm not going to pursues
- locked entry point to be a class implementing entry point interface
* fixed legacy plugins docs
* Added RegistrationInterface::registerHooksFromClass()
It mimics the way old plugins were registered in Psalm\Config, so
handler classes extending Psalm\Plugin should be fully compatible with
it.
Since Psalm\Plugin-style plugin registration was moved to
RegistrationSocket, LegacyPlugin now only load file-based plugins, so it
was renamed to FileBasedPluginAdapter.
* Converted EchoChecker plugin to composer-based format
- Its subfolder is registered as a local composer package in the root
composer.json, so it's directly installable with
```
composer require psalm/echo-checker-plugin
```
- Migration is trivial: drop the plugin into a separate folder, then add
simple composer.json and the entry point class.
* Updated docs
* Don't reject hook handlers that inherit handling methods
* strip void return type in stub file
2018-11-11 05:23:36 +01:00
|
|
|
private $config;
|
2019-03-01 14:45:18 +01:00
|
|
|
|
|
|
|
/** @var ObjectProphecy<ComposerLock> */
|
Plugin loading (#855)
* add ability to load plugins by class names
- Plugins need to implement `__invoke(PluginFacade $psalm):void` method
- Plugins are enabled by adding `<pluginClass
class="Qualified\Class\Name"/>`
- `PluginFacade` provides a single point of contact with Psalm, so that
plugins cannot become coupled to Psalm internals
* added `psalm-plugin` cli tool to manage plugins
Available commands:
`psalm-plugin list` - lists available and enabled plugins
`psalm-plugin enable 'Plugin\Class\Name'` - enables plugin (modifies `psalm.xml`)
`psalm-plugin disable 'Plugin\Class\Name'` - disables plugin (modifies `psalm.xml`)
Plugin installation:
`composer install plugin-vendor/plugin-package-name`
Plugin authoring:
Plugins are identified by package `type` field, which should contain
`psalm-plugin` string.
`extra.pluginClass` should refer to the name of the class implementing
`__invoke(PluginFacade $psalm):void` function
Todo:
- better config file search
- better output for `psalm-plugin`
- better formatting for modified xml file
- composer skeleton project for plugins
- ability to refer to plugins by package name (cli only)
- composer plugin to (optionally) enable plugin upon installation
- documentation on plugin installation and authoring
- interfaces for plugin dependencies
- interface for plugin entry point
- migration path for legacy plugins
* documented previously undocumented plugin methods
* split legacy plugin registration into a wrapper class
also added `PluginApi` namespace and `RegistrationInterface`
* reuse psalm's config search algorithm
* enable/disable plugins by composer package name
* allow specifying alternative config file name
* whitelist PluginApi namespace
three times, but well, it works now
* interface for plugin entry points
* psalm-plugin as a symfony console app
* fixed errors found by psalm
* suppressed false positive UnusedMethods
* cs fix
* better psalm-plugin output
* don't leave empty `plugins` node to avoid old schema violation
* removed junk file that shouldn't be there
* cs fix
* fixed phpunit failure (constant redefinition)
* work around missing docblock in on symfony console
* php 7.0 compatibility
* allow `pluginClass` child elements as plugin configuration
* decouple console commands from undelying implementation
- introduce PluginListFactory
- add `PluginList::enable(string $class)` and `PluginList::disable(string $class)`
* PluginList tests
* ComposerLock test
* droppped debugging statement
* added part of console command tests
* added tests for EnableCommand
* added DisableCommand tests
* ignore unused args
* ConfigFile test
* disable travis cache in attempt to fix builds
* nah, that didn't work
* update for upstream changes
* rebase fixes
* namespaced `extra` entry for entry point
* s/PluginFacade/PluginRegistrationSocket/g
* Added $config parameter to PluginEntryPointInterface::__invoke()
* cs fixes
* entry point interface php7.0 compatibility
* cleaned up old cruft
- dropped todos I'm not going to pursues
- locked entry point to be a class implementing entry point interface
* fixed legacy plugins docs
* Added RegistrationInterface::registerHooksFromClass()
It mimics the way old plugins were registered in Psalm\Config, so
handler classes extending Psalm\Plugin should be fully compatible with
it.
Since Psalm\Plugin-style plugin registration was moved to
RegistrationSocket, LegacyPlugin now only load file-based plugins, so it
was renamed to FileBasedPluginAdapter.
* Converted EchoChecker plugin to composer-based format
- Its subfolder is registered as a local composer package in the root
composer.json, so it's directly installable with
```
composer require psalm/echo-checker-plugin
```
- Migration is trivial: drop the plugin into a separate folder, then add
simple composer.json and the entry point class.
* Updated docs
* Don't reject hook handlers that inherit handling methods
* strip void return type in stub file
2018-11-11 05:23:36 +01:00
|
|
|
private $composer_lock;
|
|
|
|
|
2021-12-05 18:51:26 +01:00
|
|
|
public function setUp(): void
|
Plugin loading (#855)
* add ability to load plugins by class names
- Plugins need to implement `__invoke(PluginFacade $psalm):void` method
- Plugins are enabled by adding `<pluginClass
class="Qualified\Class\Name"/>`
- `PluginFacade` provides a single point of contact with Psalm, so that
plugins cannot become coupled to Psalm internals
* added `psalm-plugin` cli tool to manage plugins
Available commands:
`psalm-plugin list` - lists available and enabled plugins
`psalm-plugin enable 'Plugin\Class\Name'` - enables plugin (modifies `psalm.xml`)
`psalm-plugin disable 'Plugin\Class\Name'` - disables plugin (modifies `psalm.xml`)
Plugin installation:
`composer install plugin-vendor/plugin-package-name`
Plugin authoring:
Plugins are identified by package `type` field, which should contain
`psalm-plugin` string.
`extra.pluginClass` should refer to the name of the class implementing
`__invoke(PluginFacade $psalm):void` function
Todo:
- better config file search
- better output for `psalm-plugin`
- better formatting for modified xml file
- composer skeleton project for plugins
- ability to refer to plugins by package name (cli only)
- composer plugin to (optionally) enable plugin upon installation
- documentation on plugin installation and authoring
- interfaces for plugin dependencies
- interface for plugin entry point
- migration path for legacy plugins
* documented previously undocumented plugin methods
* split legacy plugin registration into a wrapper class
also added `PluginApi` namespace and `RegistrationInterface`
* reuse psalm's config search algorithm
* enable/disable plugins by composer package name
* allow specifying alternative config file name
* whitelist PluginApi namespace
three times, but well, it works now
* interface for plugin entry points
* psalm-plugin as a symfony console app
* fixed errors found by psalm
* suppressed false positive UnusedMethods
* cs fix
* better psalm-plugin output
* don't leave empty `plugins` node to avoid old schema violation
* removed junk file that shouldn't be there
* cs fix
* fixed phpunit failure (constant redefinition)
* work around missing docblock in on symfony console
* php 7.0 compatibility
* allow `pluginClass` child elements as plugin configuration
* decouple console commands from undelying implementation
- introduce PluginListFactory
- add `PluginList::enable(string $class)` and `PluginList::disable(string $class)`
* PluginList tests
* ComposerLock test
* droppped debugging statement
* added part of console command tests
* added tests for EnableCommand
* added DisableCommand tests
* ignore unused args
* ConfigFile test
* disable travis cache in attempt to fix builds
* nah, that didn't work
* update for upstream changes
* rebase fixes
* namespaced `extra` entry for entry point
* s/PluginFacade/PluginRegistrationSocket/g
* Added $config parameter to PluginEntryPointInterface::__invoke()
* cs fixes
* entry point interface php7.0 compatibility
* cleaned up old cruft
- dropped todos I'm not going to pursues
- locked entry point to be a class implementing entry point interface
* fixed legacy plugins docs
* Added RegistrationInterface::registerHooksFromClass()
It mimics the way old plugins were registered in Psalm\Config, so
handler classes extending Psalm\Plugin should be fully compatible with
it.
Since Psalm\Plugin-style plugin registration was moved to
RegistrationSocket, LegacyPlugin now only load file-based plugins, so it
was renamed to FileBasedPluginAdapter.
* Converted EchoChecker plugin to composer-based format
- Its subfolder is registered as a local composer package in the root
composer.json, so it's directly installable with
```
composer require psalm/echo-checker-plugin
```
- Migration is trivial: drop the plugin into a separate folder, then add
simple composer.json and the entry point class.
* Updated docs
* Don't reject hook handlers that inherit handling methods
* strip void return type in stub file
2018-11-11 05:23:36 +01:00
|
|
|
{
|
2020-08-23 16:32:07 +02:00
|
|
|
RuntimeCaches::clearAll();
|
|
|
|
|
Plugin loading (#855)
* add ability to load plugins by class names
- Plugins need to implement `__invoke(PluginFacade $psalm):void` method
- Plugins are enabled by adding `<pluginClass
class="Qualified\Class\Name"/>`
- `PluginFacade` provides a single point of contact with Psalm, so that
plugins cannot become coupled to Psalm internals
* added `psalm-plugin` cli tool to manage plugins
Available commands:
`psalm-plugin list` - lists available and enabled plugins
`psalm-plugin enable 'Plugin\Class\Name'` - enables plugin (modifies `psalm.xml`)
`psalm-plugin disable 'Plugin\Class\Name'` - disables plugin (modifies `psalm.xml`)
Plugin installation:
`composer install plugin-vendor/plugin-package-name`
Plugin authoring:
Plugins are identified by package `type` field, which should contain
`psalm-plugin` string.
`extra.pluginClass` should refer to the name of the class implementing
`__invoke(PluginFacade $psalm):void` function
Todo:
- better config file search
- better output for `psalm-plugin`
- better formatting for modified xml file
- composer skeleton project for plugins
- ability to refer to plugins by package name (cli only)
- composer plugin to (optionally) enable plugin upon installation
- documentation on plugin installation and authoring
- interfaces for plugin dependencies
- interface for plugin entry point
- migration path for legacy plugins
* documented previously undocumented plugin methods
* split legacy plugin registration into a wrapper class
also added `PluginApi` namespace and `RegistrationInterface`
* reuse psalm's config search algorithm
* enable/disable plugins by composer package name
* allow specifying alternative config file name
* whitelist PluginApi namespace
three times, but well, it works now
* interface for plugin entry points
* psalm-plugin as a symfony console app
* fixed errors found by psalm
* suppressed false positive UnusedMethods
* cs fix
* better psalm-plugin output
* don't leave empty `plugins` node to avoid old schema violation
* removed junk file that shouldn't be there
* cs fix
* fixed phpunit failure (constant redefinition)
* work around missing docblock in on symfony console
* php 7.0 compatibility
* allow `pluginClass` child elements as plugin configuration
* decouple console commands from undelying implementation
- introduce PluginListFactory
- add `PluginList::enable(string $class)` and `PluginList::disable(string $class)`
* PluginList tests
* ComposerLock test
* droppped debugging statement
* added part of console command tests
* added tests for EnableCommand
* added DisableCommand tests
* ignore unused args
* ConfigFile test
* disable travis cache in attempt to fix builds
* nah, that didn't work
* update for upstream changes
* rebase fixes
* namespaced `extra` entry for entry point
* s/PluginFacade/PluginRegistrationSocket/g
* Added $config parameter to PluginEntryPointInterface::__invoke()
* cs fixes
* entry point interface php7.0 compatibility
* cleaned up old cruft
- dropped todos I'm not going to pursues
- locked entry point to be a class implementing entry point interface
* fixed legacy plugins docs
* Added RegistrationInterface::registerHooksFromClass()
It mimics the way old plugins were registered in Psalm\Config, so
handler classes extending Psalm\Plugin should be fully compatible with
it.
Since Psalm\Plugin-style plugin registration was moved to
RegistrationSocket, LegacyPlugin now only load file-based plugins, so it
was renamed to FileBasedPluginAdapter.
* Converted EchoChecker plugin to composer-based format
- Its subfolder is registered as a local composer package in the root
composer.json, so it's directly installable with
```
composer require psalm/echo-checker-plugin
```
- Migration is trivial: drop the plugin into a separate folder, then add
simple composer.json and the entry point class.
* Updated docs
* Don't reject hook handlers that inherit handling methods
* strip void return type in stub file
2018-11-11 05:23:36 +01:00
|
|
|
$this->config = $this->prophesize(Config::class);
|
|
|
|
$this->config->getPluginClasses()->willReturn([]);
|
|
|
|
|
|
|
|
$this->config_file = $this->prophesize(ConfigFile::class);
|
|
|
|
$this->config_file->getConfig()->willReturn($this->config->reveal());
|
|
|
|
|
|
|
|
$this->composer_lock = $this->prophesize(ComposerLock::class);
|
|
|
|
$this->composer_lock->getPlugins()->willReturn([]);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @test
|
|
|
|
*/
|
2020-09-12 17:24:05 +02:00
|
|
|
public function pluginsPresentInConfigAreEnabled(): void
|
Plugin loading (#855)
* add ability to load plugins by class names
- Plugins need to implement `__invoke(PluginFacade $psalm):void` method
- Plugins are enabled by adding `<pluginClass
class="Qualified\Class\Name"/>`
- `PluginFacade` provides a single point of contact with Psalm, so that
plugins cannot become coupled to Psalm internals
* added `psalm-plugin` cli tool to manage plugins
Available commands:
`psalm-plugin list` - lists available and enabled plugins
`psalm-plugin enable 'Plugin\Class\Name'` - enables plugin (modifies `psalm.xml`)
`psalm-plugin disable 'Plugin\Class\Name'` - disables plugin (modifies `psalm.xml`)
Plugin installation:
`composer install plugin-vendor/plugin-package-name`
Plugin authoring:
Plugins are identified by package `type` field, which should contain
`psalm-plugin` string.
`extra.pluginClass` should refer to the name of the class implementing
`__invoke(PluginFacade $psalm):void` function
Todo:
- better config file search
- better output for `psalm-plugin`
- better formatting for modified xml file
- composer skeleton project for plugins
- ability to refer to plugins by package name (cli only)
- composer plugin to (optionally) enable plugin upon installation
- documentation on plugin installation and authoring
- interfaces for plugin dependencies
- interface for plugin entry point
- migration path for legacy plugins
* documented previously undocumented plugin methods
* split legacy plugin registration into a wrapper class
also added `PluginApi` namespace and `RegistrationInterface`
* reuse psalm's config search algorithm
* enable/disable plugins by composer package name
* allow specifying alternative config file name
* whitelist PluginApi namespace
three times, but well, it works now
* interface for plugin entry points
* psalm-plugin as a symfony console app
* fixed errors found by psalm
* suppressed false positive UnusedMethods
* cs fix
* better psalm-plugin output
* don't leave empty `plugins` node to avoid old schema violation
* removed junk file that shouldn't be there
* cs fix
* fixed phpunit failure (constant redefinition)
* work around missing docblock in on symfony console
* php 7.0 compatibility
* allow `pluginClass` child elements as plugin configuration
* decouple console commands from undelying implementation
- introduce PluginListFactory
- add `PluginList::enable(string $class)` and `PluginList::disable(string $class)`
* PluginList tests
* ComposerLock test
* droppped debugging statement
* added part of console command tests
* added tests for EnableCommand
* added DisableCommand tests
* ignore unused args
* ConfigFile test
* disable travis cache in attempt to fix builds
* nah, that didn't work
* update for upstream changes
* rebase fixes
* namespaced `extra` entry for entry point
* s/PluginFacade/PluginRegistrationSocket/g
* Added $config parameter to PluginEntryPointInterface::__invoke()
* cs fixes
* entry point interface php7.0 compatibility
* cleaned up old cruft
- dropped todos I'm not going to pursues
- locked entry point to be a class implementing entry point interface
* fixed legacy plugins docs
* Added RegistrationInterface::registerHooksFromClass()
It mimics the way old plugins were registered in Psalm\Config, so
handler classes extending Psalm\Plugin should be fully compatible with
it.
Since Psalm\Plugin-style plugin registration was moved to
RegistrationSocket, LegacyPlugin now only load file-based plugins, so it
was renamed to FileBasedPluginAdapter.
* Converted EchoChecker plugin to composer-based format
- Its subfolder is registered as a local composer package in the root
composer.json, so it's directly installable with
```
composer require psalm/echo-checker-plugin
```
- Migration is trivial: drop the plugin into a separate folder, then add
simple composer.json and the entry point class.
* Updated docs
* Don't reject hook handlers that inherit handling methods
* strip void return type in stub file
2018-11-11 05:23:36 +01:00
|
|
|
{
|
|
|
|
$this->config->getPluginClasses()->willReturn([
|
|
|
|
['class' => 'a\b\c', 'config' => null],
|
|
|
|
['class' => 'c\d\e', 'config' => null],
|
|
|
|
]);
|
|
|
|
|
|
|
|
$plugin_list = new PluginList($this->config_file->reveal(), $this->composer_lock->reveal());
|
|
|
|
|
2019-03-23 19:27:54 +01:00
|
|
|
$this->assertSame([
|
Plugin loading (#855)
* add ability to load plugins by class names
- Plugins need to implement `__invoke(PluginFacade $psalm):void` method
- Plugins are enabled by adding `<pluginClass
class="Qualified\Class\Name"/>`
- `PluginFacade` provides a single point of contact with Psalm, so that
plugins cannot become coupled to Psalm internals
* added `psalm-plugin` cli tool to manage plugins
Available commands:
`psalm-plugin list` - lists available and enabled plugins
`psalm-plugin enable 'Plugin\Class\Name'` - enables plugin (modifies `psalm.xml`)
`psalm-plugin disable 'Plugin\Class\Name'` - disables plugin (modifies `psalm.xml`)
Plugin installation:
`composer install plugin-vendor/plugin-package-name`
Plugin authoring:
Plugins are identified by package `type` field, which should contain
`psalm-plugin` string.
`extra.pluginClass` should refer to the name of the class implementing
`__invoke(PluginFacade $psalm):void` function
Todo:
- better config file search
- better output for `psalm-plugin`
- better formatting for modified xml file
- composer skeleton project for plugins
- ability to refer to plugins by package name (cli only)
- composer plugin to (optionally) enable plugin upon installation
- documentation on plugin installation and authoring
- interfaces for plugin dependencies
- interface for plugin entry point
- migration path for legacy plugins
* documented previously undocumented plugin methods
* split legacy plugin registration into a wrapper class
also added `PluginApi` namespace and `RegistrationInterface`
* reuse psalm's config search algorithm
* enable/disable plugins by composer package name
* allow specifying alternative config file name
* whitelist PluginApi namespace
three times, but well, it works now
* interface for plugin entry points
* psalm-plugin as a symfony console app
* fixed errors found by psalm
* suppressed false positive UnusedMethods
* cs fix
* better psalm-plugin output
* don't leave empty `plugins` node to avoid old schema violation
* removed junk file that shouldn't be there
* cs fix
* fixed phpunit failure (constant redefinition)
* work around missing docblock in on symfony console
* php 7.0 compatibility
* allow `pluginClass` child elements as plugin configuration
* decouple console commands from undelying implementation
- introduce PluginListFactory
- add `PluginList::enable(string $class)` and `PluginList::disable(string $class)`
* PluginList tests
* ComposerLock test
* droppped debugging statement
* added part of console command tests
* added tests for EnableCommand
* added DisableCommand tests
* ignore unused args
* ConfigFile test
* disable travis cache in attempt to fix builds
* nah, that didn't work
* update for upstream changes
* rebase fixes
* namespaced `extra` entry for entry point
* s/PluginFacade/PluginRegistrationSocket/g
* Added $config parameter to PluginEntryPointInterface::__invoke()
* cs fixes
* entry point interface php7.0 compatibility
* cleaned up old cruft
- dropped todos I'm not going to pursues
- locked entry point to be a class implementing entry point interface
* fixed legacy plugins docs
* Added RegistrationInterface::registerHooksFromClass()
It mimics the way old plugins were registered in Psalm\Config, so
handler classes extending Psalm\Plugin should be fully compatible with
it.
Since Psalm\Plugin-style plugin registration was moved to
RegistrationSocket, LegacyPlugin now only load file-based plugins, so it
was renamed to FileBasedPluginAdapter.
* Converted EchoChecker plugin to composer-based format
- Its subfolder is registered as a local composer package in the root
composer.json, so it's directly installable with
```
composer require psalm/echo-checker-plugin
```
- Migration is trivial: drop the plugin into a separate folder, then add
simple composer.json and the entry point class.
* Updated docs
* Don't reject hook handlers that inherit handling methods
* strip void return type in stub file
2018-11-11 05:23:36 +01:00
|
|
|
'a\b\c' => null,
|
|
|
|
'c\d\e' => null,
|
|
|
|
], $plugin_list->getEnabled());
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @test
|
|
|
|
*/
|
2020-09-12 17:24:05 +02:00
|
|
|
public function pluginsPresentInPackageLockOnlyAreAvailable(): void
|
Plugin loading (#855)
* add ability to load plugins by class names
- Plugins need to implement `__invoke(PluginFacade $psalm):void` method
- Plugins are enabled by adding `<pluginClass
class="Qualified\Class\Name"/>`
- `PluginFacade` provides a single point of contact with Psalm, so that
plugins cannot become coupled to Psalm internals
* added `psalm-plugin` cli tool to manage plugins
Available commands:
`psalm-plugin list` - lists available and enabled plugins
`psalm-plugin enable 'Plugin\Class\Name'` - enables plugin (modifies `psalm.xml`)
`psalm-plugin disable 'Plugin\Class\Name'` - disables plugin (modifies `psalm.xml`)
Plugin installation:
`composer install plugin-vendor/plugin-package-name`
Plugin authoring:
Plugins are identified by package `type` field, which should contain
`psalm-plugin` string.
`extra.pluginClass` should refer to the name of the class implementing
`__invoke(PluginFacade $psalm):void` function
Todo:
- better config file search
- better output for `psalm-plugin`
- better formatting for modified xml file
- composer skeleton project for plugins
- ability to refer to plugins by package name (cli only)
- composer plugin to (optionally) enable plugin upon installation
- documentation on plugin installation and authoring
- interfaces for plugin dependencies
- interface for plugin entry point
- migration path for legacy plugins
* documented previously undocumented plugin methods
* split legacy plugin registration into a wrapper class
also added `PluginApi` namespace and `RegistrationInterface`
* reuse psalm's config search algorithm
* enable/disable plugins by composer package name
* allow specifying alternative config file name
* whitelist PluginApi namespace
three times, but well, it works now
* interface for plugin entry points
* psalm-plugin as a symfony console app
* fixed errors found by psalm
* suppressed false positive UnusedMethods
* cs fix
* better psalm-plugin output
* don't leave empty `plugins` node to avoid old schema violation
* removed junk file that shouldn't be there
* cs fix
* fixed phpunit failure (constant redefinition)
* work around missing docblock in on symfony console
* php 7.0 compatibility
* allow `pluginClass` child elements as plugin configuration
* decouple console commands from undelying implementation
- introduce PluginListFactory
- add `PluginList::enable(string $class)` and `PluginList::disable(string $class)`
* PluginList tests
* ComposerLock test
* droppped debugging statement
* added part of console command tests
* added tests for EnableCommand
* added DisableCommand tests
* ignore unused args
* ConfigFile test
* disable travis cache in attempt to fix builds
* nah, that didn't work
* update for upstream changes
* rebase fixes
* namespaced `extra` entry for entry point
* s/PluginFacade/PluginRegistrationSocket/g
* Added $config parameter to PluginEntryPointInterface::__invoke()
* cs fixes
* entry point interface php7.0 compatibility
* cleaned up old cruft
- dropped todos I'm not going to pursues
- locked entry point to be a class implementing entry point interface
* fixed legacy plugins docs
* Added RegistrationInterface::registerHooksFromClass()
It mimics the way old plugins were registered in Psalm\Config, so
handler classes extending Psalm\Plugin should be fully compatible with
it.
Since Psalm\Plugin-style plugin registration was moved to
RegistrationSocket, LegacyPlugin now only load file-based plugins, so it
was renamed to FileBasedPluginAdapter.
* Converted EchoChecker plugin to composer-based format
- Its subfolder is registered as a local composer package in the root
composer.json, so it's directly installable with
```
composer require psalm/echo-checker-plugin
```
- Migration is trivial: drop the plugin into a separate folder, then add
simple composer.json and the entry point class.
* Updated docs
* Don't reject hook handlers that inherit handling methods
* strip void return type in stub file
2018-11-11 05:23:36 +01:00
|
|
|
{
|
|
|
|
$this->config->getPluginClasses()->willReturn([
|
|
|
|
['class' => 'a\b\c', 'config' => null],
|
|
|
|
]);
|
|
|
|
|
|
|
|
$this->composer_lock->getPlugins()->willReturn([
|
|
|
|
'vendor/package' => 'a\b\c',
|
|
|
|
'another-vendor/another-package' => 'c\d\e',
|
|
|
|
]);
|
|
|
|
|
|
|
|
$plugin_list = new PluginList($this->config_file->reveal(), $this->composer_lock->reveal());
|
|
|
|
|
2019-03-23 19:27:54 +01:00
|
|
|
$this->assertSame([
|
Plugin loading (#855)
* add ability to load plugins by class names
- Plugins need to implement `__invoke(PluginFacade $psalm):void` method
- Plugins are enabled by adding `<pluginClass
class="Qualified\Class\Name"/>`
- `PluginFacade` provides a single point of contact with Psalm, so that
plugins cannot become coupled to Psalm internals
* added `psalm-plugin` cli tool to manage plugins
Available commands:
`psalm-plugin list` - lists available and enabled plugins
`psalm-plugin enable 'Plugin\Class\Name'` - enables plugin (modifies `psalm.xml`)
`psalm-plugin disable 'Plugin\Class\Name'` - disables plugin (modifies `psalm.xml`)
Plugin installation:
`composer install plugin-vendor/plugin-package-name`
Plugin authoring:
Plugins are identified by package `type` field, which should contain
`psalm-plugin` string.
`extra.pluginClass` should refer to the name of the class implementing
`__invoke(PluginFacade $psalm):void` function
Todo:
- better config file search
- better output for `psalm-plugin`
- better formatting for modified xml file
- composer skeleton project for plugins
- ability to refer to plugins by package name (cli only)
- composer plugin to (optionally) enable plugin upon installation
- documentation on plugin installation and authoring
- interfaces for plugin dependencies
- interface for plugin entry point
- migration path for legacy plugins
* documented previously undocumented plugin methods
* split legacy plugin registration into a wrapper class
also added `PluginApi` namespace and `RegistrationInterface`
* reuse psalm's config search algorithm
* enable/disable plugins by composer package name
* allow specifying alternative config file name
* whitelist PluginApi namespace
three times, but well, it works now
* interface for plugin entry points
* psalm-plugin as a symfony console app
* fixed errors found by psalm
* suppressed false positive UnusedMethods
* cs fix
* better psalm-plugin output
* don't leave empty `plugins` node to avoid old schema violation
* removed junk file that shouldn't be there
* cs fix
* fixed phpunit failure (constant redefinition)
* work around missing docblock in on symfony console
* php 7.0 compatibility
* allow `pluginClass` child elements as plugin configuration
* decouple console commands from undelying implementation
- introduce PluginListFactory
- add `PluginList::enable(string $class)` and `PluginList::disable(string $class)`
* PluginList tests
* ComposerLock test
* droppped debugging statement
* added part of console command tests
* added tests for EnableCommand
* added DisableCommand tests
* ignore unused args
* ConfigFile test
* disable travis cache in attempt to fix builds
* nah, that didn't work
* update for upstream changes
* rebase fixes
* namespaced `extra` entry for entry point
* s/PluginFacade/PluginRegistrationSocket/g
* Added $config parameter to PluginEntryPointInterface::__invoke()
* cs fixes
* entry point interface php7.0 compatibility
* cleaned up old cruft
- dropped todos I'm not going to pursues
- locked entry point to be a class implementing entry point interface
* fixed legacy plugins docs
* Added RegistrationInterface::registerHooksFromClass()
It mimics the way old plugins were registered in Psalm\Config, so
handler classes extending Psalm\Plugin should be fully compatible with
it.
Since Psalm\Plugin-style plugin registration was moved to
RegistrationSocket, LegacyPlugin now only load file-based plugins, so it
was renamed to FileBasedPluginAdapter.
* Converted EchoChecker plugin to composer-based format
- Its subfolder is registered as a local composer package in the root
composer.json, so it's directly installable with
```
composer require psalm/echo-checker-plugin
```
- Migration is trivial: drop the plugin into a separate folder, then add
simple composer.json and the entry point class.
* Updated docs
* Don't reject hook handlers that inherit handling methods
* strip void return type in stub file
2018-11-11 05:23:36 +01:00
|
|
|
'c\d\e' => 'another-vendor/another-package',
|
|
|
|
], $plugin_list->getAvailable());
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @test
|
|
|
|
*/
|
2020-09-12 17:24:05 +02:00
|
|
|
public function pluginsPresentInPackageLockAndConfigHavePluginPackageName(): void
|
Plugin loading (#855)
* add ability to load plugins by class names
- Plugins need to implement `__invoke(PluginFacade $psalm):void` method
- Plugins are enabled by adding `<pluginClass
class="Qualified\Class\Name"/>`
- `PluginFacade` provides a single point of contact with Psalm, so that
plugins cannot become coupled to Psalm internals
* added `psalm-plugin` cli tool to manage plugins
Available commands:
`psalm-plugin list` - lists available and enabled plugins
`psalm-plugin enable 'Plugin\Class\Name'` - enables plugin (modifies `psalm.xml`)
`psalm-plugin disable 'Plugin\Class\Name'` - disables plugin (modifies `psalm.xml`)
Plugin installation:
`composer install plugin-vendor/plugin-package-name`
Plugin authoring:
Plugins are identified by package `type` field, which should contain
`psalm-plugin` string.
`extra.pluginClass` should refer to the name of the class implementing
`__invoke(PluginFacade $psalm):void` function
Todo:
- better config file search
- better output for `psalm-plugin`
- better formatting for modified xml file
- composer skeleton project for plugins
- ability to refer to plugins by package name (cli only)
- composer plugin to (optionally) enable plugin upon installation
- documentation on plugin installation and authoring
- interfaces for plugin dependencies
- interface for plugin entry point
- migration path for legacy plugins
* documented previously undocumented plugin methods
* split legacy plugin registration into a wrapper class
also added `PluginApi` namespace and `RegistrationInterface`
* reuse psalm's config search algorithm
* enable/disable plugins by composer package name
* allow specifying alternative config file name
* whitelist PluginApi namespace
three times, but well, it works now
* interface for plugin entry points
* psalm-plugin as a symfony console app
* fixed errors found by psalm
* suppressed false positive UnusedMethods
* cs fix
* better psalm-plugin output
* don't leave empty `plugins` node to avoid old schema violation
* removed junk file that shouldn't be there
* cs fix
* fixed phpunit failure (constant redefinition)
* work around missing docblock in on symfony console
* php 7.0 compatibility
* allow `pluginClass` child elements as plugin configuration
* decouple console commands from undelying implementation
- introduce PluginListFactory
- add `PluginList::enable(string $class)` and `PluginList::disable(string $class)`
* PluginList tests
* ComposerLock test
* droppped debugging statement
* added part of console command tests
* added tests for EnableCommand
* added DisableCommand tests
* ignore unused args
* ConfigFile test
* disable travis cache in attempt to fix builds
* nah, that didn't work
* update for upstream changes
* rebase fixes
* namespaced `extra` entry for entry point
* s/PluginFacade/PluginRegistrationSocket/g
* Added $config parameter to PluginEntryPointInterface::__invoke()
* cs fixes
* entry point interface php7.0 compatibility
* cleaned up old cruft
- dropped todos I'm not going to pursues
- locked entry point to be a class implementing entry point interface
* fixed legacy plugins docs
* Added RegistrationInterface::registerHooksFromClass()
It mimics the way old plugins were registered in Psalm\Config, so
handler classes extending Psalm\Plugin should be fully compatible with
it.
Since Psalm\Plugin-style plugin registration was moved to
RegistrationSocket, LegacyPlugin now only load file-based plugins, so it
was renamed to FileBasedPluginAdapter.
* Converted EchoChecker plugin to composer-based format
- Its subfolder is registered as a local composer package in the root
composer.json, so it's directly installable with
```
composer require psalm/echo-checker-plugin
```
- Migration is trivial: drop the plugin into a separate folder, then add
simple composer.json and the entry point class.
* Updated docs
* Don't reject hook handlers that inherit handling methods
* strip void return type in stub file
2018-11-11 05:23:36 +01:00
|
|
|
{
|
|
|
|
$this->config->getPluginClasses()->willReturn([
|
|
|
|
['class' => 'a\b\c', 'config' => null],
|
|
|
|
]);
|
|
|
|
|
|
|
|
$this->composer_lock->getPlugins()->willReturn([
|
|
|
|
'vendor/package' => 'a\b\c',
|
|
|
|
]);
|
|
|
|
|
|
|
|
$plugin_list = new PluginList($this->config_file->reveal(), $this->composer_lock->reveal());
|
|
|
|
|
2019-03-23 19:27:54 +01:00
|
|
|
$this->assertSame([
|
Plugin loading (#855)
* add ability to load plugins by class names
- Plugins need to implement `__invoke(PluginFacade $psalm):void` method
- Plugins are enabled by adding `<pluginClass
class="Qualified\Class\Name"/>`
- `PluginFacade` provides a single point of contact with Psalm, so that
plugins cannot become coupled to Psalm internals
* added `psalm-plugin` cli tool to manage plugins
Available commands:
`psalm-plugin list` - lists available and enabled plugins
`psalm-plugin enable 'Plugin\Class\Name'` - enables plugin (modifies `psalm.xml`)
`psalm-plugin disable 'Plugin\Class\Name'` - disables plugin (modifies `psalm.xml`)
Plugin installation:
`composer install plugin-vendor/plugin-package-name`
Plugin authoring:
Plugins are identified by package `type` field, which should contain
`psalm-plugin` string.
`extra.pluginClass` should refer to the name of the class implementing
`__invoke(PluginFacade $psalm):void` function
Todo:
- better config file search
- better output for `psalm-plugin`
- better formatting for modified xml file
- composer skeleton project for plugins
- ability to refer to plugins by package name (cli only)
- composer plugin to (optionally) enable plugin upon installation
- documentation on plugin installation and authoring
- interfaces for plugin dependencies
- interface for plugin entry point
- migration path for legacy plugins
* documented previously undocumented plugin methods
* split legacy plugin registration into a wrapper class
also added `PluginApi` namespace and `RegistrationInterface`
* reuse psalm's config search algorithm
* enable/disable plugins by composer package name
* allow specifying alternative config file name
* whitelist PluginApi namespace
three times, but well, it works now
* interface for plugin entry points
* psalm-plugin as a symfony console app
* fixed errors found by psalm
* suppressed false positive UnusedMethods
* cs fix
* better psalm-plugin output
* don't leave empty `plugins` node to avoid old schema violation
* removed junk file that shouldn't be there
* cs fix
* fixed phpunit failure (constant redefinition)
* work around missing docblock in on symfony console
* php 7.0 compatibility
* allow `pluginClass` child elements as plugin configuration
* decouple console commands from undelying implementation
- introduce PluginListFactory
- add `PluginList::enable(string $class)` and `PluginList::disable(string $class)`
* PluginList tests
* ComposerLock test
* droppped debugging statement
* added part of console command tests
* added tests for EnableCommand
* added DisableCommand tests
* ignore unused args
* ConfigFile test
* disable travis cache in attempt to fix builds
* nah, that didn't work
* update for upstream changes
* rebase fixes
* namespaced `extra` entry for entry point
* s/PluginFacade/PluginRegistrationSocket/g
* Added $config parameter to PluginEntryPointInterface::__invoke()
* cs fixes
* entry point interface php7.0 compatibility
* cleaned up old cruft
- dropped todos I'm not going to pursues
- locked entry point to be a class implementing entry point interface
* fixed legacy plugins docs
* Added RegistrationInterface::registerHooksFromClass()
It mimics the way old plugins were registered in Psalm\Config, so
handler classes extending Psalm\Plugin should be fully compatible with
it.
Since Psalm\Plugin-style plugin registration was moved to
RegistrationSocket, LegacyPlugin now only load file-based plugins, so it
was renamed to FileBasedPluginAdapter.
* Converted EchoChecker plugin to composer-based format
- Its subfolder is registered as a local composer package in the root
composer.json, so it's directly installable with
```
composer require psalm/echo-checker-plugin
```
- Migration is trivial: drop the plugin into a separate folder, then add
simple composer.json and the entry point class.
* Updated docs
* Don't reject hook handlers that inherit handling methods
* strip void return type in stub file
2018-11-11 05:23:36 +01:00
|
|
|
'a\b\c' => 'vendor/package',
|
|
|
|
], $plugin_list->getEnabled());
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @test
|
|
|
|
*/
|
2020-09-12 17:24:05 +02:00
|
|
|
public function canFindPluginClassByClassName(): void
|
Plugin loading (#855)
* add ability to load plugins by class names
- Plugins need to implement `__invoke(PluginFacade $psalm):void` method
- Plugins are enabled by adding `<pluginClass
class="Qualified\Class\Name"/>`
- `PluginFacade` provides a single point of contact with Psalm, so that
plugins cannot become coupled to Psalm internals
* added `psalm-plugin` cli tool to manage plugins
Available commands:
`psalm-plugin list` - lists available and enabled plugins
`psalm-plugin enable 'Plugin\Class\Name'` - enables plugin (modifies `psalm.xml`)
`psalm-plugin disable 'Plugin\Class\Name'` - disables plugin (modifies `psalm.xml`)
Plugin installation:
`composer install plugin-vendor/plugin-package-name`
Plugin authoring:
Plugins are identified by package `type` field, which should contain
`psalm-plugin` string.
`extra.pluginClass` should refer to the name of the class implementing
`__invoke(PluginFacade $psalm):void` function
Todo:
- better config file search
- better output for `psalm-plugin`
- better formatting for modified xml file
- composer skeleton project for plugins
- ability to refer to plugins by package name (cli only)
- composer plugin to (optionally) enable plugin upon installation
- documentation on plugin installation and authoring
- interfaces for plugin dependencies
- interface for plugin entry point
- migration path for legacy plugins
* documented previously undocumented plugin methods
* split legacy plugin registration into a wrapper class
also added `PluginApi` namespace and `RegistrationInterface`
* reuse psalm's config search algorithm
* enable/disable plugins by composer package name
* allow specifying alternative config file name
* whitelist PluginApi namespace
three times, but well, it works now
* interface for plugin entry points
* psalm-plugin as a symfony console app
* fixed errors found by psalm
* suppressed false positive UnusedMethods
* cs fix
* better psalm-plugin output
* don't leave empty `plugins` node to avoid old schema violation
* removed junk file that shouldn't be there
* cs fix
* fixed phpunit failure (constant redefinition)
* work around missing docblock in on symfony console
* php 7.0 compatibility
* allow `pluginClass` child elements as plugin configuration
* decouple console commands from undelying implementation
- introduce PluginListFactory
- add `PluginList::enable(string $class)` and `PluginList::disable(string $class)`
* PluginList tests
* ComposerLock test
* droppped debugging statement
* added part of console command tests
* added tests for EnableCommand
* added DisableCommand tests
* ignore unused args
* ConfigFile test
* disable travis cache in attempt to fix builds
* nah, that didn't work
* update for upstream changes
* rebase fixes
* namespaced `extra` entry for entry point
* s/PluginFacade/PluginRegistrationSocket/g
* Added $config parameter to PluginEntryPointInterface::__invoke()
* cs fixes
* entry point interface php7.0 compatibility
* cleaned up old cruft
- dropped todos I'm not going to pursues
- locked entry point to be a class implementing entry point interface
* fixed legacy plugins docs
* Added RegistrationInterface::registerHooksFromClass()
It mimics the way old plugins were registered in Psalm\Config, so
handler classes extending Psalm\Plugin should be fully compatible with
it.
Since Psalm\Plugin-style plugin registration was moved to
RegistrationSocket, LegacyPlugin now only load file-based plugins, so it
was renamed to FileBasedPluginAdapter.
* Converted EchoChecker plugin to composer-based format
- Its subfolder is registered as a local composer package in the root
composer.json, so it's directly installable with
```
composer require psalm/echo-checker-plugin
```
- Migration is trivial: drop the plugin into a separate folder, then add
simple composer.json and the entry point class.
* Updated docs
* Don't reject hook handlers that inherit handling methods
* strip void return type in stub file
2018-11-11 05:23:36 +01:00
|
|
|
{
|
|
|
|
$plugin_list = new PluginList($this->config_file->reveal(), $this->composer_lock->reveal());
|
2019-03-23 19:27:54 +01:00
|
|
|
$this->assertSame('a\b\c', $plugin_list->resolvePluginClass('a\b\c'));
|
Plugin loading (#855)
* add ability to load plugins by class names
- Plugins need to implement `__invoke(PluginFacade $psalm):void` method
- Plugins are enabled by adding `<pluginClass
class="Qualified\Class\Name"/>`
- `PluginFacade` provides a single point of contact with Psalm, so that
plugins cannot become coupled to Psalm internals
* added `psalm-plugin` cli tool to manage plugins
Available commands:
`psalm-plugin list` - lists available and enabled plugins
`psalm-plugin enable 'Plugin\Class\Name'` - enables plugin (modifies `psalm.xml`)
`psalm-plugin disable 'Plugin\Class\Name'` - disables plugin (modifies `psalm.xml`)
Plugin installation:
`composer install plugin-vendor/plugin-package-name`
Plugin authoring:
Plugins are identified by package `type` field, which should contain
`psalm-plugin` string.
`extra.pluginClass` should refer to the name of the class implementing
`__invoke(PluginFacade $psalm):void` function
Todo:
- better config file search
- better output for `psalm-plugin`
- better formatting for modified xml file
- composer skeleton project for plugins
- ability to refer to plugins by package name (cli only)
- composer plugin to (optionally) enable plugin upon installation
- documentation on plugin installation and authoring
- interfaces for plugin dependencies
- interface for plugin entry point
- migration path for legacy plugins
* documented previously undocumented plugin methods
* split legacy plugin registration into a wrapper class
also added `PluginApi` namespace and `RegistrationInterface`
* reuse psalm's config search algorithm
* enable/disable plugins by composer package name
* allow specifying alternative config file name
* whitelist PluginApi namespace
three times, but well, it works now
* interface for plugin entry points
* psalm-plugin as a symfony console app
* fixed errors found by psalm
* suppressed false positive UnusedMethods
* cs fix
* better psalm-plugin output
* don't leave empty `plugins` node to avoid old schema violation
* removed junk file that shouldn't be there
* cs fix
* fixed phpunit failure (constant redefinition)
* work around missing docblock in on symfony console
* php 7.0 compatibility
* allow `pluginClass` child elements as plugin configuration
* decouple console commands from undelying implementation
- introduce PluginListFactory
- add `PluginList::enable(string $class)` and `PluginList::disable(string $class)`
* PluginList tests
* ComposerLock test
* droppped debugging statement
* added part of console command tests
* added tests for EnableCommand
* added DisableCommand tests
* ignore unused args
* ConfigFile test
* disable travis cache in attempt to fix builds
* nah, that didn't work
* update for upstream changes
* rebase fixes
* namespaced `extra` entry for entry point
* s/PluginFacade/PluginRegistrationSocket/g
* Added $config parameter to PluginEntryPointInterface::__invoke()
* cs fixes
* entry point interface php7.0 compatibility
* cleaned up old cruft
- dropped todos I'm not going to pursues
- locked entry point to be a class implementing entry point interface
* fixed legacy plugins docs
* Added RegistrationInterface::registerHooksFromClass()
It mimics the way old plugins were registered in Psalm\Config, so
handler classes extending Psalm\Plugin should be fully compatible with
it.
Since Psalm\Plugin-style plugin registration was moved to
RegistrationSocket, LegacyPlugin now only load file-based plugins, so it
was renamed to FileBasedPluginAdapter.
* Converted EchoChecker plugin to composer-based format
- Its subfolder is registered as a local composer package in the root
composer.json, so it's directly installable with
```
composer require psalm/echo-checker-plugin
```
- Migration is trivial: drop the plugin into a separate folder, then add
simple composer.json and the entry point class.
* Updated docs
* Don't reject hook handlers that inherit handling methods
* strip void return type in stub file
2018-11-11 05:23:36 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @test
|
|
|
|
*/
|
2020-09-12 17:24:05 +02:00
|
|
|
public function canFindPluginClassByPackageName(): void
|
Plugin loading (#855)
* add ability to load plugins by class names
- Plugins need to implement `__invoke(PluginFacade $psalm):void` method
- Plugins are enabled by adding `<pluginClass
class="Qualified\Class\Name"/>`
- `PluginFacade` provides a single point of contact with Psalm, so that
plugins cannot become coupled to Psalm internals
* added `psalm-plugin` cli tool to manage plugins
Available commands:
`psalm-plugin list` - lists available and enabled plugins
`psalm-plugin enable 'Plugin\Class\Name'` - enables plugin (modifies `psalm.xml`)
`psalm-plugin disable 'Plugin\Class\Name'` - disables plugin (modifies `psalm.xml`)
Plugin installation:
`composer install plugin-vendor/plugin-package-name`
Plugin authoring:
Plugins are identified by package `type` field, which should contain
`psalm-plugin` string.
`extra.pluginClass` should refer to the name of the class implementing
`__invoke(PluginFacade $psalm):void` function
Todo:
- better config file search
- better output for `psalm-plugin`
- better formatting for modified xml file
- composer skeleton project for plugins
- ability to refer to plugins by package name (cli only)
- composer plugin to (optionally) enable plugin upon installation
- documentation on plugin installation and authoring
- interfaces for plugin dependencies
- interface for plugin entry point
- migration path for legacy plugins
* documented previously undocumented plugin methods
* split legacy plugin registration into a wrapper class
also added `PluginApi` namespace and `RegistrationInterface`
* reuse psalm's config search algorithm
* enable/disable plugins by composer package name
* allow specifying alternative config file name
* whitelist PluginApi namespace
three times, but well, it works now
* interface for plugin entry points
* psalm-plugin as a symfony console app
* fixed errors found by psalm
* suppressed false positive UnusedMethods
* cs fix
* better psalm-plugin output
* don't leave empty `plugins` node to avoid old schema violation
* removed junk file that shouldn't be there
* cs fix
* fixed phpunit failure (constant redefinition)
* work around missing docblock in on symfony console
* php 7.0 compatibility
* allow `pluginClass` child elements as plugin configuration
* decouple console commands from undelying implementation
- introduce PluginListFactory
- add `PluginList::enable(string $class)` and `PluginList::disable(string $class)`
* PluginList tests
* ComposerLock test
* droppped debugging statement
* added part of console command tests
* added tests for EnableCommand
* added DisableCommand tests
* ignore unused args
* ConfigFile test
* disable travis cache in attempt to fix builds
* nah, that didn't work
* update for upstream changes
* rebase fixes
* namespaced `extra` entry for entry point
* s/PluginFacade/PluginRegistrationSocket/g
* Added $config parameter to PluginEntryPointInterface::__invoke()
* cs fixes
* entry point interface php7.0 compatibility
* cleaned up old cruft
- dropped todos I'm not going to pursues
- locked entry point to be a class implementing entry point interface
* fixed legacy plugins docs
* Added RegistrationInterface::registerHooksFromClass()
It mimics the way old plugins were registered in Psalm\Config, so
handler classes extending Psalm\Plugin should be fully compatible with
it.
Since Psalm\Plugin-style plugin registration was moved to
RegistrationSocket, LegacyPlugin now only load file-based plugins, so it
was renamed to FileBasedPluginAdapter.
* Converted EchoChecker plugin to composer-based format
- Its subfolder is registered as a local composer package in the root
composer.json, so it's directly installable with
```
composer require psalm/echo-checker-plugin
```
- Migration is trivial: drop the plugin into a separate folder, then add
simple composer.json and the entry point class.
* Updated docs
* Don't reject hook handlers that inherit handling methods
* strip void return type in stub file
2018-11-11 05:23:36 +01:00
|
|
|
{
|
|
|
|
$this->composer_lock->getPlugins()->willReturn([
|
|
|
|
'vendor/package' => 'a\b\c',
|
|
|
|
]);
|
|
|
|
|
|
|
|
$plugin_list = new PluginList($this->config_file->reveal(), $this->composer_lock->reveal());
|
2019-03-23 19:27:54 +01:00
|
|
|
$this->assertSame('a\b\c', $plugin_list->resolvePluginClass('vendor/package'));
|
Plugin loading (#855)
* add ability to load plugins by class names
- Plugins need to implement `__invoke(PluginFacade $psalm):void` method
- Plugins are enabled by adding `<pluginClass
class="Qualified\Class\Name"/>`
- `PluginFacade` provides a single point of contact with Psalm, so that
plugins cannot become coupled to Psalm internals
* added `psalm-plugin` cli tool to manage plugins
Available commands:
`psalm-plugin list` - lists available and enabled plugins
`psalm-plugin enable 'Plugin\Class\Name'` - enables plugin (modifies `psalm.xml`)
`psalm-plugin disable 'Plugin\Class\Name'` - disables plugin (modifies `psalm.xml`)
Plugin installation:
`composer install plugin-vendor/plugin-package-name`
Plugin authoring:
Plugins are identified by package `type` field, which should contain
`psalm-plugin` string.
`extra.pluginClass` should refer to the name of the class implementing
`__invoke(PluginFacade $psalm):void` function
Todo:
- better config file search
- better output for `psalm-plugin`
- better formatting for modified xml file
- composer skeleton project for plugins
- ability to refer to plugins by package name (cli only)
- composer plugin to (optionally) enable plugin upon installation
- documentation on plugin installation and authoring
- interfaces for plugin dependencies
- interface for plugin entry point
- migration path for legacy plugins
* documented previously undocumented plugin methods
* split legacy plugin registration into a wrapper class
also added `PluginApi` namespace and `RegistrationInterface`
* reuse psalm's config search algorithm
* enable/disable plugins by composer package name
* allow specifying alternative config file name
* whitelist PluginApi namespace
three times, but well, it works now
* interface for plugin entry points
* psalm-plugin as a symfony console app
* fixed errors found by psalm
* suppressed false positive UnusedMethods
* cs fix
* better psalm-plugin output
* don't leave empty `plugins` node to avoid old schema violation
* removed junk file that shouldn't be there
* cs fix
* fixed phpunit failure (constant redefinition)
* work around missing docblock in on symfony console
* php 7.0 compatibility
* allow `pluginClass` child elements as plugin configuration
* decouple console commands from undelying implementation
- introduce PluginListFactory
- add `PluginList::enable(string $class)` and `PluginList::disable(string $class)`
* PluginList tests
* ComposerLock test
* droppped debugging statement
* added part of console command tests
* added tests for EnableCommand
* added DisableCommand tests
* ignore unused args
* ConfigFile test
* disable travis cache in attempt to fix builds
* nah, that didn't work
* update for upstream changes
* rebase fixes
* namespaced `extra` entry for entry point
* s/PluginFacade/PluginRegistrationSocket/g
* Added $config parameter to PluginEntryPointInterface::__invoke()
* cs fixes
* entry point interface php7.0 compatibility
* cleaned up old cruft
- dropped todos I'm not going to pursues
- locked entry point to be a class implementing entry point interface
* fixed legacy plugins docs
* Added RegistrationInterface::registerHooksFromClass()
It mimics the way old plugins were registered in Psalm\Config, so
handler classes extending Psalm\Plugin should be fully compatible with
it.
Since Psalm\Plugin-style plugin registration was moved to
RegistrationSocket, LegacyPlugin now only load file-based plugins, so it
was renamed to FileBasedPluginAdapter.
* Converted EchoChecker plugin to composer-based format
- Its subfolder is registered as a local composer package in the root
composer.json, so it's directly installable with
```
composer require psalm/echo-checker-plugin
```
- Migration is trivial: drop the plugin into a separate folder, then add
simple composer.json and the entry point class.
* Updated docs
* Don't reject hook handlers that inherit handling methods
* strip void return type in stub file
2018-11-11 05:23:36 +01:00
|
|
|
}
|
|
|
|
|
2020-11-20 15:54:14 +01:00
|
|
|
/**
|
|
|
|
* @test
|
|
|
|
*/
|
|
|
|
public function canShowAvailablePluginsWithoutAConfigFile(): void
|
|
|
|
{
|
|
|
|
$this->composer_lock->getPlugins()->willReturn([
|
|
|
|
'vendor/package' => 'a\b\c',
|
|
|
|
'another-vendor/another-package' => 'c\d\e',
|
|
|
|
]);
|
|
|
|
$plugin_list = new PluginList(null, $this->composer_lock->reveal());
|
|
|
|
|
|
|
|
$this->assertSame([
|
|
|
|
'a\b\c' => 'vendor/package',
|
|
|
|
'c\d\e' => 'another-vendor/another-package',
|
|
|
|
], $plugin_list->getAvailable());
|
|
|
|
}
|
|
|
|
|
Plugin loading (#855)
* add ability to load plugins by class names
- Plugins need to implement `__invoke(PluginFacade $psalm):void` method
- Plugins are enabled by adding `<pluginClass
class="Qualified\Class\Name"/>`
- `PluginFacade` provides a single point of contact with Psalm, so that
plugins cannot become coupled to Psalm internals
* added `psalm-plugin` cli tool to manage plugins
Available commands:
`psalm-plugin list` - lists available and enabled plugins
`psalm-plugin enable 'Plugin\Class\Name'` - enables plugin (modifies `psalm.xml`)
`psalm-plugin disable 'Plugin\Class\Name'` - disables plugin (modifies `psalm.xml`)
Plugin installation:
`composer install plugin-vendor/plugin-package-name`
Plugin authoring:
Plugins are identified by package `type` field, which should contain
`psalm-plugin` string.
`extra.pluginClass` should refer to the name of the class implementing
`__invoke(PluginFacade $psalm):void` function
Todo:
- better config file search
- better output for `psalm-plugin`
- better formatting for modified xml file
- composer skeleton project for plugins
- ability to refer to plugins by package name (cli only)
- composer plugin to (optionally) enable plugin upon installation
- documentation on plugin installation and authoring
- interfaces for plugin dependencies
- interface for plugin entry point
- migration path for legacy plugins
* documented previously undocumented plugin methods
* split legacy plugin registration into a wrapper class
also added `PluginApi` namespace and `RegistrationInterface`
* reuse psalm's config search algorithm
* enable/disable plugins by composer package name
* allow specifying alternative config file name
* whitelist PluginApi namespace
three times, but well, it works now
* interface for plugin entry points
* psalm-plugin as a symfony console app
* fixed errors found by psalm
* suppressed false positive UnusedMethods
* cs fix
* better psalm-plugin output
* don't leave empty `plugins` node to avoid old schema violation
* removed junk file that shouldn't be there
* cs fix
* fixed phpunit failure (constant redefinition)
* work around missing docblock in on symfony console
* php 7.0 compatibility
* allow `pluginClass` child elements as plugin configuration
* decouple console commands from undelying implementation
- introduce PluginListFactory
- add `PluginList::enable(string $class)` and `PluginList::disable(string $class)`
* PluginList tests
* ComposerLock test
* droppped debugging statement
* added part of console command tests
* added tests for EnableCommand
* added DisableCommand tests
* ignore unused args
* ConfigFile test
* disable travis cache in attempt to fix builds
* nah, that didn't work
* update for upstream changes
* rebase fixes
* namespaced `extra` entry for entry point
* s/PluginFacade/PluginRegistrationSocket/g
* Added $config parameter to PluginEntryPointInterface::__invoke()
* cs fixes
* entry point interface php7.0 compatibility
* cleaned up old cruft
- dropped todos I'm not going to pursues
- locked entry point to be a class implementing entry point interface
* fixed legacy plugins docs
* Added RegistrationInterface::registerHooksFromClass()
It mimics the way old plugins were registered in Psalm\Config, so
handler classes extending Psalm\Plugin should be fully compatible with
it.
Since Psalm\Plugin-style plugin registration was moved to
RegistrationSocket, LegacyPlugin now only load file-based plugins, so it
was renamed to FileBasedPluginAdapter.
* Converted EchoChecker plugin to composer-based format
- Its subfolder is registered as a local composer package in the root
composer.json, so it's directly installable with
```
composer require psalm/echo-checker-plugin
```
- Migration is trivial: drop the plugin into a separate folder, then add
simple composer.json and the entry point class.
* Updated docs
* Don't reject hook handlers that inherit handling methods
* strip void return type in stub file
2018-11-11 05:23:36 +01:00
|
|
|
/**
|
|
|
|
* @test
|
|
|
|
*/
|
2020-09-12 17:24:05 +02:00
|
|
|
public function enabledPackageIsEnabled(): void
|
Plugin loading (#855)
* add ability to load plugins by class names
- Plugins need to implement `__invoke(PluginFacade $psalm):void` method
- Plugins are enabled by adding `<pluginClass
class="Qualified\Class\Name"/>`
- `PluginFacade` provides a single point of contact with Psalm, so that
plugins cannot become coupled to Psalm internals
* added `psalm-plugin` cli tool to manage plugins
Available commands:
`psalm-plugin list` - lists available and enabled plugins
`psalm-plugin enable 'Plugin\Class\Name'` - enables plugin (modifies `psalm.xml`)
`psalm-plugin disable 'Plugin\Class\Name'` - disables plugin (modifies `psalm.xml`)
Plugin installation:
`composer install plugin-vendor/plugin-package-name`
Plugin authoring:
Plugins are identified by package `type` field, which should contain
`psalm-plugin` string.
`extra.pluginClass` should refer to the name of the class implementing
`__invoke(PluginFacade $psalm):void` function
Todo:
- better config file search
- better output for `psalm-plugin`
- better formatting for modified xml file
- composer skeleton project for plugins
- ability to refer to plugins by package name (cli only)
- composer plugin to (optionally) enable plugin upon installation
- documentation on plugin installation and authoring
- interfaces for plugin dependencies
- interface for plugin entry point
- migration path for legacy plugins
* documented previously undocumented plugin methods
* split legacy plugin registration into a wrapper class
also added `PluginApi` namespace and `RegistrationInterface`
* reuse psalm's config search algorithm
* enable/disable plugins by composer package name
* allow specifying alternative config file name
* whitelist PluginApi namespace
three times, but well, it works now
* interface for plugin entry points
* psalm-plugin as a symfony console app
* fixed errors found by psalm
* suppressed false positive UnusedMethods
* cs fix
* better psalm-plugin output
* don't leave empty `plugins` node to avoid old schema violation
* removed junk file that shouldn't be there
* cs fix
* fixed phpunit failure (constant redefinition)
* work around missing docblock in on symfony console
* php 7.0 compatibility
* allow `pluginClass` child elements as plugin configuration
* decouple console commands from undelying implementation
- introduce PluginListFactory
- add `PluginList::enable(string $class)` and `PluginList::disable(string $class)`
* PluginList tests
* ComposerLock test
* droppped debugging statement
* added part of console command tests
* added tests for EnableCommand
* added DisableCommand tests
* ignore unused args
* ConfigFile test
* disable travis cache in attempt to fix builds
* nah, that didn't work
* update for upstream changes
* rebase fixes
* namespaced `extra` entry for entry point
* s/PluginFacade/PluginRegistrationSocket/g
* Added $config parameter to PluginEntryPointInterface::__invoke()
* cs fixes
* entry point interface php7.0 compatibility
* cleaned up old cruft
- dropped todos I'm not going to pursues
- locked entry point to be a class implementing entry point interface
* fixed legacy plugins docs
* Added RegistrationInterface::registerHooksFromClass()
It mimics the way old plugins were registered in Psalm\Config, so
handler classes extending Psalm\Plugin should be fully compatible with
it.
Since Psalm\Plugin-style plugin registration was moved to
RegistrationSocket, LegacyPlugin now only load file-based plugins, so it
was renamed to FileBasedPluginAdapter.
* Converted EchoChecker plugin to composer-based format
- Its subfolder is registered as a local composer package in the root
composer.json, so it's directly installable with
```
composer require psalm/echo-checker-plugin
```
- Migration is trivial: drop the plugin into a separate folder, then add
simple composer.json and the entry point class.
* Updated docs
* Don't reject hook handlers that inherit handling methods
* strip void return type in stub file
2018-11-11 05:23:36 +01:00
|
|
|
{
|
|
|
|
$this->config->getPluginClasses()->willReturn([
|
|
|
|
['class' => 'a\b\c', 'config' => null],
|
|
|
|
]);
|
|
|
|
|
|
|
|
$plugin_list = new PluginList($this->config_file->reveal(), $this->composer_lock->reveal());
|
|
|
|
|
|
|
|
$this->assertTrue($plugin_list->isEnabled('a\b\c'));
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @test
|
|
|
|
*/
|
2020-09-12 17:24:05 +02:00
|
|
|
public function errorsOutWhenTryingToResolveUnknownPlugin(): void
|
Plugin loading (#855)
* add ability to load plugins by class names
- Plugins need to implement `__invoke(PluginFacade $psalm):void` method
- Plugins are enabled by adding `<pluginClass
class="Qualified\Class\Name"/>`
- `PluginFacade` provides a single point of contact with Psalm, so that
plugins cannot become coupled to Psalm internals
* added `psalm-plugin` cli tool to manage plugins
Available commands:
`psalm-plugin list` - lists available and enabled plugins
`psalm-plugin enable 'Plugin\Class\Name'` - enables plugin (modifies `psalm.xml`)
`psalm-plugin disable 'Plugin\Class\Name'` - disables plugin (modifies `psalm.xml`)
Plugin installation:
`composer install plugin-vendor/plugin-package-name`
Plugin authoring:
Plugins are identified by package `type` field, which should contain
`psalm-plugin` string.
`extra.pluginClass` should refer to the name of the class implementing
`__invoke(PluginFacade $psalm):void` function
Todo:
- better config file search
- better output for `psalm-plugin`
- better formatting for modified xml file
- composer skeleton project for plugins
- ability to refer to plugins by package name (cli only)
- composer plugin to (optionally) enable plugin upon installation
- documentation on plugin installation and authoring
- interfaces for plugin dependencies
- interface for plugin entry point
- migration path for legacy plugins
* documented previously undocumented plugin methods
* split legacy plugin registration into a wrapper class
also added `PluginApi` namespace and `RegistrationInterface`
* reuse psalm's config search algorithm
* enable/disable plugins by composer package name
* allow specifying alternative config file name
* whitelist PluginApi namespace
three times, but well, it works now
* interface for plugin entry points
* psalm-plugin as a symfony console app
* fixed errors found by psalm
* suppressed false positive UnusedMethods
* cs fix
* better psalm-plugin output
* don't leave empty `plugins` node to avoid old schema violation
* removed junk file that shouldn't be there
* cs fix
* fixed phpunit failure (constant redefinition)
* work around missing docblock in on symfony console
* php 7.0 compatibility
* allow `pluginClass` child elements as plugin configuration
* decouple console commands from undelying implementation
- introduce PluginListFactory
- add `PluginList::enable(string $class)` and `PluginList::disable(string $class)`
* PluginList tests
* ComposerLock test
* droppped debugging statement
* added part of console command tests
* added tests for EnableCommand
* added DisableCommand tests
* ignore unused args
* ConfigFile test
* disable travis cache in attempt to fix builds
* nah, that didn't work
* update for upstream changes
* rebase fixes
* namespaced `extra` entry for entry point
* s/PluginFacade/PluginRegistrationSocket/g
* Added $config parameter to PluginEntryPointInterface::__invoke()
* cs fixes
* entry point interface php7.0 compatibility
* cleaned up old cruft
- dropped todos I'm not going to pursues
- locked entry point to be a class implementing entry point interface
* fixed legacy plugins docs
* Added RegistrationInterface::registerHooksFromClass()
It mimics the way old plugins were registered in Psalm\Config, so
handler classes extending Psalm\Plugin should be fully compatible with
it.
Since Psalm\Plugin-style plugin registration was moved to
RegistrationSocket, LegacyPlugin now only load file-based plugins, so it
was renamed to FileBasedPluginAdapter.
* Converted EchoChecker plugin to composer-based format
- Its subfolder is registered as a local composer package in the root
composer.json, so it's directly installable with
```
composer require psalm/echo-checker-plugin
```
- Migration is trivial: drop the plugin into a separate folder, then add
simple composer.json and the entry point class.
* Updated docs
* Don't reject hook handlers that inherit handling methods
* strip void return type in stub file
2018-11-11 05:23:36 +01:00
|
|
|
{
|
|
|
|
$plugin_list = new PluginList($this->config_file->reveal(), $this->composer_lock->reveal());
|
2021-12-03 21:40:18 +01:00
|
|
|
$this->expectException(InvalidArgumentException::class);
|
Plugin loading (#855)
* add ability to load plugins by class names
- Plugins need to implement `__invoke(PluginFacade $psalm):void` method
- Plugins are enabled by adding `<pluginClass
class="Qualified\Class\Name"/>`
- `PluginFacade` provides a single point of contact with Psalm, so that
plugins cannot become coupled to Psalm internals
* added `psalm-plugin` cli tool to manage plugins
Available commands:
`psalm-plugin list` - lists available and enabled plugins
`psalm-plugin enable 'Plugin\Class\Name'` - enables plugin (modifies `psalm.xml`)
`psalm-plugin disable 'Plugin\Class\Name'` - disables plugin (modifies `psalm.xml`)
Plugin installation:
`composer install plugin-vendor/plugin-package-name`
Plugin authoring:
Plugins are identified by package `type` field, which should contain
`psalm-plugin` string.
`extra.pluginClass` should refer to the name of the class implementing
`__invoke(PluginFacade $psalm):void` function
Todo:
- better config file search
- better output for `psalm-plugin`
- better formatting for modified xml file
- composer skeleton project for plugins
- ability to refer to plugins by package name (cli only)
- composer plugin to (optionally) enable plugin upon installation
- documentation on plugin installation and authoring
- interfaces for plugin dependencies
- interface for plugin entry point
- migration path for legacy plugins
* documented previously undocumented plugin methods
* split legacy plugin registration into a wrapper class
also added `PluginApi` namespace and `RegistrationInterface`
* reuse psalm's config search algorithm
* enable/disable plugins by composer package name
* allow specifying alternative config file name
* whitelist PluginApi namespace
three times, but well, it works now
* interface for plugin entry points
* psalm-plugin as a symfony console app
* fixed errors found by psalm
* suppressed false positive UnusedMethods
* cs fix
* better psalm-plugin output
* don't leave empty `plugins` node to avoid old schema violation
* removed junk file that shouldn't be there
* cs fix
* fixed phpunit failure (constant redefinition)
* work around missing docblock in on symfony console
* php 7.0 compatibility
* allow `pluginClass` child elements as plugin configuration
* decouple console commands from undelying implementation
- introduce PluginListFactory
- add `PluginList::enable(string $class)` and `PluginList::disable(string $class)`
* PluginList tests
* ComposerLock test
* droppped debugging statement
* added part of console command tests
* added tests for EnableCommand
* added DisableCommand tests
* ignore unused args
* ConfigFile test
* disable travis cache in attempt to fix builds
* nah, that didn't work
* update for upstream changes
* rebase fixes
* namespaced `extra` entry for entry point
* s/PluginFacade/PluginRegistrationSocket/g
* Added $config parameter to PluginEntryPointInterface::__invoke()
* cs fixes
* entry point interface php7.0 compatibility
* cleaned up old cruft
- dropped todos I'm not going to pursues
- locked entry point to be a class implementing entry point interface
* fixed legacy plugins docs
* Added RegistrationInterface::registerHooksFromClass()
It mimics the way old plugins were registered in Psalm\Config, so
handler classes extending Psalm\Plugin should be fully compatible with
it.
Since Psalm\Plugin-style plugin registration was moved to
RegistrationSocket, LegacyPlugin now only load file-based plugins, so it
was renamed to FileBasedPluginAdapter.
* Converted EchoChecker plugin to composer-based format
- Its subfolder is registered as a local composer package in the root
composer.json, so it's directly installable with
```
composer require psalm/echo-checker-plugin
```
- Migration is trivial: drop the plugin into a separate folder, then add
simple composer.json and the entry point class.
* Updated docs
* Don't reject hook handlers that inherit handling methods
* strip void return type in stub file
2018-11-11 05:23:36 +01:00
|
|
|
$this->expectExceptionMessageRegExp('/unknown plugin/i');
|
|
|
|
$plugin_list->resolvePluginClass('vendor/package');
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @test
|
|
|
|
*/
|
2020-09-12 17:24:05 +02:00
|
|
|
public function pluginsAreEnabledInConfigFile(): void
|
Plugin loading (#855)
* add ability to load plugins by class names
- Plugins need to implement `__invoke(PluginFacade $psalm):void` method
- Plugins are enabled by adding `<pluginClass
class="Qualified\Class\Name"/>`
- `PluginFacade` provides a single point of contact with Psalm, so that
plugins cannot become coupled to Psalm internals
* added `psalm-plugin` cli tool to manage plugins
Available commands:
`psalm-plugin list` - lists available and enabled plugins
`psalm-plugin enable 'Plugin\Class\Name'` - enables plugin (modifies `psalm.xml`)
`psalm-plugin disable 'Plugin\Class\Name'` - disables plugin (modifies `psalm.xml`)
Plugin installation:
`composer install plugin-vendor/plugin-package-name`
Plugin authoring:
Plugins are identified by package `type` field, which should contain
`psalm-plugin` string.
`extra.pluginClass` should refer to the name of the class implementing
`__invoke(PluginFacade $psalm):void` function
Todo:
- better config file search
- better output for `psalm-plugin`
- better formatting for modified xml file
- composer skeleton project for plugins
- ability to refer to plugins by package name (cli only)
- composer plugin to (optionally) enable plugin upon installation
- documentation on plugin installation and authoring
- interfaces for plugin dependencies
- interface for plugin entry point
- migration path for legacy plugins
* documented previously undocumented plugin methods
* split legacy plugin registration into a wrapper class
also added `PluginApi` namespace and `RegistrationInterface`
* reuse psalm's config search algorithm
* enable/disable plugins by composer package name
* allow specifying alternative config file name
* whitelist PluginApi namespace
three times, but well, it works now
* interface for plugin entry points
* psalm-plugin as a symfony console app
* fixed errors found by psalm
* suppressed false positive UnusedMethods
* cs fix
* better psalm-plugin output
* don't leave empty `plugins` node to avoid old schema violation
* removed junk file that shouldn't be there
* cs fix
* fixed phpunit failure (constant redefinition)
* work around missing docblock in on symfony console
* php 7.0 compatibility
* allow `pluginClass` child elements as plugin configuration
* decouple console commands from undelying implementation
- introduce PluginListFactory
- add `PluginList::enable(string $class)` and `PluginList::disable(string $class)`
* PluginList tests
* ComposerLock test
* droppped debugging statement
* added part of console command tests
* added tests for EnableCommand
* added DisableCommand tests
* ignore unused args
* ConfigFile test
* disable travis cache in attempt to fix builds
* nah, that didn't work
* update for upstream changes
* rebase fixes
* namespaced `extra` entry for entry point
* s/PluginFacade/PluginRegistrationSocket/g
* Added $config parameter to PluginEntryPointInterface::__invoke()
* cs fixes
* entry point interface php7.0 compatibility
* cleaned up old cruft
- dropped todos I'm not going to pursues
- locked entry point to be a class implementing entry point interface
* fixed legacy plugins docs
* Added RegistrationInterface::registerHooksFromClass()
It mimics the way old plugins were registered in Psalm\Config, so
handler classes extending Psalm\Plugin should be fully compatible with
it.
Since Psalm\Plugin-style plugin registration was moved to
RegistrationSocket, LegacyPlugin now only load file-based plugins, so it
was renamed to FileBasedPluginAdapter.
* Converted EchoChecker plugin to composer-based format
- Its subfolder is registered as a local composer package in the root
composer.json, so it's directly installable with
```
composer require psalm/echo-checker-plugin
```
- Migration is trivial: drop the plugin into a separate folder, then add
simple composer.json and the entry point class.
* Updated docs
* Don't reject hook handlers that inherit handling methods
* strip void return type in stub file
2018-11-11 05:23:36 +01:00
|
|
|
{
|
|
|
|
$plugin_list = new PluginList($this->config_file->reveal(), $this->composer_lock->reveal());
|
|
|
|
|
|
|
|
$this->config_file->addPlugin('a\b\c')->shouldBeCalled();
|
|
|
|
|
|
|
|
$plugin_list->enable('a\b\c');
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @test
|
|
|
|
*/
|
2020-09-12 17:24:05 +02:00
|
|
|
public function pluginsAreDisabledInConfigFile(): void
|
Plugin loading (#855)
* add ability to load plugins by class names
- Plugins need to implement `__invoke(PluginFacade $psalm):void` method
- Plugins are enabled by adding `<pluginClass
class="Qualified\Class\Name"/>`
- `PluginFacade` provides a single point of contact with Psalm, so that
plugins cannot become coupled to Psalm internals
* added `psalm-plugin` cli tool to manage plugins
Available commands:
`psalm-plugin list` - lists available and enabled plugins
`psalm-plugin enable 'Plugin\Class\Name'` - enables plugin (modifies `psalm.xml`)
`psalm-plugin disable 'Plugin\Class\Name'` - disables plugin (modifies `psalm.xml`)
Plugin installation:
`composer install plugin-vendor/plugin-package-name`
Plugin authoring:
Plugins are identified by package `type` field, which should contain
`psalm-plugin` string.
`extra.pluginClass` should refer to the name of the class implementing
`__invoke(PluginFacade $psalm):void` function
Todo:
- better config file search
- better output for `psalm-plugin`
- better formatting for modified xml file
- composer skeleton project for plugins
- ability to refer to plugins by package name (cli only)
- composer plugin to (optionally) enable plugin upon installation
- documentation on plugin installation and authoring
- interfaces for plugin dependencies
- interface for plugin entry point
- migration path for legacy plugins
* documented previously undocumented plugin methods
* split legacy plugin registration into a wrapper class
also added `PluginApi` namespace and `RegistrationInterface`
* reuse psalm's config search algorithm
* enable/disable plugins by composer package name
* allow specifying alternative config file name
* whitelist PluginApi namespace
three times, but well, it works now
* interface for plugin entry points
* psalm-plugin as a symfony console app
* fixed errors found by psalm
* suppressed false positive UnusedMethods
* cs fix
* better psalm-plugin output
* don't leave empty `plugins` node to avoid old schema violation
* removed junk file that shouldn't be there
* cs fix
* fixed phpunit failure (constant redefinition)
* work around missing docblock in on symfony console
* php 7.0 compatibility
* allow `pluginClass` child elements as plugin configuration
* decouple console commands from undelying implementation
- introduce PluginListFactory
- add `PluginList::enable(string $class)` and `PluginList::disable(string $class)`
* PluginList tests
* ComposerLock test
* droppped debugging statement
* added part of console command tests
* added tests for EnableCommand
* added DisableCommand tests
* ignore unused args
* ConfigFile test
* disable travis cache in attempt to fix builds
* nah, that didn't work
* update for upstream changes
* rebase fixes
* namespaced `extra` entry for entry point
* s/PluginFacade/PluginRegistrationSocket/g
* Added $config parameter to PluginEntryPointInterface::__invoke()
* cs fixes
* entry point interface php7.0 compatibility
* cleaned up old cruft
- dropped todos I'm not going to pursues
- locked entry point to be a class implementing entry point interface
* fixed legacy plugins docs
* Added RegistrationInterface::registerHooksFromClass()
It mimics the way old plugins were registered in Psalm\Config, so
handler classes extending Psalm\Plugin should be fully compatible with
it.
Since Psalm\Plugin-style plugin registration was moved to
RegistrationSocket, LegacyPlugin now only load file-based plugins, so it
was renamed to FileBasedPluginAdapter.
* Converted EchoChecker plugin to composer-based format
- Its subfolder is registered as a local composer package in the root
composer.json, so it's directly installable with
```
composer require psalm/echo-checker-plugin
```
- Migration is trivial: drop the plugin into a separate folder, then add
simple composer.json and the entry point class.
* Updated docs
* Don't reject hook handlers that inherit handling methods
* strip void return type in stub file
2018-11-11 05:23:36 +01:00
|
|
|
{
|
|
|
|
$plugin_list = new PluginList($this->config_file->reveal(), $this->composer_lock->reveal());
|
|
|
|
|
|
|
|
$this->config_file->removePlugin('a\b\c')->shouldBeCalled();
|
|
|
|
|
|
|
|
$plugin_list->disable('a\b\c');
|
|
|
|
}
|
|
|
|
}
|