Following \Psalm\Plugin\RegistrationInterface methods are deprecated
+ addFileTypeScanner
+ addFileTypeAnalyzer
Following \Psalm\PluginRegistrationSocket methods are deprecated
+ addFileTypeScanner
+ getAdditionalFileTypeScanners
+ addFileTypeAnalyzer
+ getAdditionalFileTypeAnalyzers
+ getAdditionalFileExtensions
+ addFileExtension
Mentioned methods will be removed in Psalm v5.0, corresponding
functionality will be provided by following new interfaces and classes
+ \Psalm\Plugin\FileExtensionsInterface
+ \Psalm\PluginFileExtensionsSocket
Related: #6788
This change does a few things:
* Renames `BeforeAnalyzeFileInterface` to `BeforeFileAnalysisInterface`.
* Adds a few more parameters to `BeforeFileAnalysisInterface`.
* Since the analysis was never called due to a bug, the above two
changes are safe to do.
* Fix the above-mentioned bug, and now adds the hooks to the config.
* Update the documentation about the File-related analysis plugin hooks.
* Add a test to ensure that this does not break again in the future.
Fixes: #3969
compared to AfterFunctionCallAnalysisInterface which gets only called
after a call to a function declared within the project, a plugin
implementing AfterEveryFunctionCallAnalysisInterface will get called for
every function call, including calls of PHP builtins.
On the other hand, this interface doesn't allow modification of the code
nor tweaking the return type, but it's still useful for accounting
purposes and for depreacting calls to PHP builtins
this fixes#2804
* Add a bunch of new hooks
* Add more integrations
* Add some broken tests
* Add more things
* Fix remaining interfaces
* Suppress proper issue
* UndefinedMethod should not stop analysis
* Add handlers for two custom method return types
* 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
