vscode-phpcs
vscode-phpcs copied to clipboard
ikappas
unmaintained?
It looks like this project hasn't been maintained for 3 years. It also looks there is now a maintained fork at https://github.com/shevaua/vscode-phpcs
Am I right?
This fork seems a little more up to date ATOW: https://github.com/ETubaro/vscode-phpcs
This one works good as well: https://github.com/wongjn/vscode-php-sniffer Solved my problems with the original extension.
I found myself very unhappy with the solutions that are available and made this: https://github.com/ObliviousHarmony/vscode-php-codesniffer
@mattheworres , @kapxapot , @ObliviousHarmony , we see 3 different alternatives, but none of them detail what the differences are with current @ikappas' solution.
Could any one make a comparison of what the differences are? What improvements are vs vscode-phpcs? What parts are still missing to port? Why do you prefer the other one?
@str, not sure, but I had some problems with applying rulesets from the local phpcs.xml file + resolving custom rulesets from referenced libraries.
I think that's a fair criticism @str and indicates it may be good to add such an explanation to my readme. For a little context, I recently made the switch from PHPStorm to VS Code and so it was somewhat jarring to find how much less supported the PHP ecosystem is.
When I examined the current options I found four major deficits:
- PHPCS is executed synchronously
- No QuickFix support
- No "Ignore * for this line" support
- No support for document formatting or incorrect support for range formatting
After examining the VS Code API it was apparent that an extension would actually have no problem supporting these features. My first thought was to contribute to an existing project but after seeing all of the pending PRs and issues in most repositories I felt that would be a waste of my time. My extension was born out of a desire to create something of the quality of PHPStorm's integration. While I'm sure it isn't perfect, I did manage to resolve the above deficits and create something that I personally feel is easier to use.
@ObliviousHarmony, thanks for the information. I'm sorry if I sounded too blunt, or if my comment sounded like criticism. I just wanted to know in advance instead of going one by one and not knowing what to look for.
Those new features that your plugin has sound great. There are some features of @ikappas ' vscode-phpcs that are great, or probably I'm already used to that are not supported in your extension that still forces me to stay with it. I really hope you continue with your project so we can have better tools for PHP in VS Ecosystem.
What can I do to help? Can I make a list of the features I see missing in your version that @ikappas version has so we can make a roadmap?
My current killer feature is the support of phpcs.xml per folder. For example, I'm working on a WordPress plugin and we use PSR-12, but WordPress has it's own CS, so I have a phpcs.xml in the root level pointing to WP-CS, and my plugin has it's own phpcs.xml pointing to PSR-12. @ObliviousHarmony , I undertsand you need to define the CS as a global setting using phpCodeSniffer.standard, am I right?
Again, what can I do to help?
@str I'd assume you can make it less global and set settings per workspace, and I believe VSCode allows you to have multiple workspaces open at the same time (in the same window, not separate windows) - might seem a bit arduous and less than intuitive, but I think it gets you there? @ObliviousHarmony if you can, I believe Github added a discussion board to projects last year, it might be a good space to move this conversation (and others that can prop up) there.
When I have time, I'll certainly investigate migrating over to your extension, right now shevaua's is working well enough. Thanks for all the hard work thus far!
@str
I'm sorry if I sounded too blunt, or if my comment sounded like criticism.
Not at all! While I work in open-source software professionally, I've never actually released anything myself. I took your comment as feedback indicating my readme is insufficient in explaining why my extension is different than the ten others available already.
What can I do to help? Can I make a list of the features I see missing in your version that @ikappas version has so we can make a roadmap?
Please feel free to open any enhancement requests for important features that you think the extension is missing and we can discuss them there!
I undertsand you need to define the CS as a global setting using phpCodeSniffer.standard, am I right?
While I haven't tested it in that context explicitly, I did add support for a Default option in phpCodeSniffer.standard. This option causes the extension to pass no explicit standard and allows PHPCS to decide what standard to use based on its own internal logic. Looking at the documentation however, it seems like this would only work in cases where the folder has a vendor/bin/phpcs and phpCodeSniffer.autoExecutable is enabled. Could you open an issue in the repository if this is insufficient in your use-case? Adding support through directory traversal would be trivial, though I'll note that if the executable it uses does not have the sniff called for in the XML file defined it will error.
@mattheworres
Yeah, I'd prefer to have this discussion in that repository because it doesn't really belong here :) I just wanted to add another alternative to this issue.
Hi everyone,
Most of the issues reported in this repository are PHP_CodeSniffer configuration related most of which fall into the ignoring/failing to read documentation (both vscode-plugin and PHP_CodeSniffer)
Sure there are borderline cases that this plugin does not accommodate, features that could be added, and bugs that should be addressed but the vast majority of users have used this plugin early on after VSCode initial release back in 2015 to get things done in PHP. In most part, at least in the context of my day to day work, the plugin works surprisingly well considering it's last commit was in 2018.
Nevertheless, over the years people complaint about this and that and the other, without ever getting into contributing back a solution. Even in my sparse time, I would have an look and review a solid proposal for a new feature or a fix that would accommodate the majority of the plugin users.
So I would be more than happy to get more people involved in maintaining this plugin and evolving it into a community driven project.
I am open to suggestions.
PS: I would like to take the opportunity and thank all the people that have contributed their time to address the various issues people experienced over the past 5+ years and helped others get things done using this plugin.
@ikappas thank you for your great work.
You are right, most reported issues could be addressed by changing some configuration, probably in the phpcs.xml. I don't think people are complaining about your plugin, I think they feel lost without any replies to their issues. Now that I'm more familiar with PHPCS, I'll try to answer issues I think can be solved by setting the right configuration.
I'll see if I can make time to dig into the plugin's code to see if I can, not only report issues, but try code solutions.
@ObliviousHarmony
Please feel free to open any enhancement requests for important features that you think the extension is missing and we can discuss them there!
I'll try to make a feature-request/enhancement list by creating issues here: https://github.com/ikappas/vscode-phpcs/issues/created_by/str
I, like many others, came with an issue that I solved later with a configuration change.
[O]ver the years people complaint about this and that and the other, without ever getting into contributing back a solution. So I would be more than happy to get more people involved in maintaining this plugin and evolving it into a community driven project.
You have 13 open pull requests.
