* Add new config: sealAllMethods
* Add some more tests
* Fix codesniffer issue with preg_quote
* Fix missing method in test
Co-authored-by: Olle <noemail>
as suggested in the PR it's best to make the setting configurable.
In order not to break existing installations, we default to keeping the
old behaviour, but in a later version of psalm, we might change the
default.
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
if a composer.json is present and a PHP version requirement is
configured, we set the php version to the minimal PHP version that
satisfies the composer requirement.
Additionally, this adds a `phpVersion` attribute to the <psalm> tag. If
that's set, it takes precedence over what has been detected in
composer.json.
And finally, the --php-version command line flag continues to work and
takes precedence over the setting in the <psalm> tag
this fixes#2628
* check if phpstorm meta path is a file or directory, making a note if it was a directory, re: #2640
* import is_file()
* overcautiously glob into meta directory
This change introduces an option to have the configuration split across
several files using standard XInclude tags. This may be useful for more
complex configs, or to include auto-generated parts into a manually
written config file.
* Extract function getPsalmHelpText() from psalm.php
* Extract initialiseConfig from psalm.php
* Add -c as valid short option for psalter and psalm-refactor
* Use initialiseConfig in psalter, psalm-refactor and psalm-language-server as well as psalm
* Rely on psalm --alter resolving directory from config file in test
* Remove erronous condition for config file path
This code was based on me wrongly thinking that the config file location
was seprated from the argument name with a space instead of an equals
sign
* Use config dir as current dir in psalm and psalm-refactor, as with psalter and psalm-language-server
* Remove redundant duplicated code
* Refactor: move calls to \Psalm\Config::setComposerClassLoader inside initialiseConfig
* PHPCS fix
* Extract function get_path_to_config from command scripts
* Refactor - extract functions from \Psalm\Config::loadFromXML
* Refactor - reduce verbosity of config loading code
* Allow running e2e tests on windows
* Fix testCompactReport on Windows
* convert line endings to make testCompactReport pass on Windows
* Add resolveFromConfigFile config option
Treats all paths as relative to the location of the config file, not
the current working directory of the process.
This commit just changes psalm, further commits will be needed to
apply the change to psalter and the LSP server.
* Copy asset xml files into project root for testing, delete during teardown
Needed since paths are now resolved relative to the position of the
file.
Not sure why I only saw a test failre for 1.xml - would have expected it
for all eight files.
* Fix following rebase
* Move psalm --init handly code above working directory setting code
If there's no psalm.xml yet we can't use the location of psalm.xml to
set our working directory
* Move Psalm version output code above working directory resolution
Working directory doesn't need to be known to output version constant
* Rely on new config file based working directory in end to end test
* Dont use rely on config dir for --alter - not currently working
* Fix code style error
* Add failing test for supporting config without `resolveFromConfigFile="true"`
* Don't treat config directory as a path to check
* Document resolveFromConfigFile setting
Since functions defined in files referenced in 'files' section in
composer autoload config are automatically loaded when composer
autoloader is included (for example when Psalm is installed into project
vendors), it's good idea to keep them namespaced. Otherwise it would
prevent dependents to declare their own functions in the global
namespace with the same names.
* Fall back to autoload when loading plugin classes
This allows to use plugins installed alongside Psalm (when it's not
installed in the project being analyzed).
This fixes (partially) vimeo/psalm#1710
* cs fix
* Fixedvimeo/psalm#1714
Moved `isAbsolutePath()` into a functions file (`src/functions.php`)
that is now automatically loaded by composer autoload.
/cc: @jwage
* Dropped redundant bootstrap
* Revert "Revert "Implement better progress""
This reverts commit 4302596654.
* Revert "Revert "Implement dots progress bar""
This reverts commit e41733d789.
* Revert "Revert "Switch to VoidProgress by default""
This reverts commit 304ffeb0a3.
* Revert "Revert "Pass success flag to progress""
This reverts commit 62a690ee4e.
* Improve socket communication
* Use an underscore
* Add means to disable progress
* Add extra newline before progress bar
* 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
1. Variable ids can contain slashes or dots, e.g. for `${'my/var'} = 2`
or psalm's local representation of properties or array indexes
(I forget which)
2. preg_quote's escape character should **always** be the same as the
pattern starting character.
Using DIRECTORY_SEPARATOR will fail to escape '/' on windows.
