How do I pass options to the phpcs linter?

[dafeder]

Question

PHPCS generally takes a specific coding standard (Drupal, PSR2 etc) for sniffs. It is not clear to me how to specify this to the plugin, or what standards are available.

How to reproduce (optional)

Expected behavior (optional)

No response

CLI Version

qlty 0.485.0 linux-x64 (fd779b6 2025-02-07)

Information about Qlty configuration and environment (optional)

config_version = "0"

exclude_patterns = [
  "cypress/",
  "config/",
  "db/",
  "dist/",
  "docs/",
  "documentation/",
  "features/",
  "**/node_modules/",
  "script/",
  "**/spec/",
  "**/test/",
  "**/tests/",
  "Tests/",
  "**/vendor/",
  "**/*_test.go",
  "**/*.d.ts",
  "**/*.yml",
  "**/*.json",
  "**/*.js",
  "**/*.jsx",
  "*.md",
  "**/*.md",
  "*.install",
  "*.profile",
  "*.module",
  "*.xml",
  "**/*.xml",
  "**/*.install",
  "**/*.profile",
  "**/*.module",
  ".circleci/",
  ".gitignore",
]

test_patterns = [
  "**/test/**",
  "**/tests/**",
  "**/Tests/**",
]

[smells]
mode = "block"

[[source]]
name = "default"
default = true

[[plugin]]
name = "bandit"
version = "1.7.9"

[[plugin]]
name = "checkov"

[[plugin]]
name = "golangci-lint"

[[plugin]]
name = "markdownlint"
version = "0.41.0"

[[plugin]]
name = "osv-scanner"

[[plugin]]
name = "php-codesniffer"

[[plugin]]
name = "phpstan"

[[plugin]]
name = "prettier"

[[plugin]]
name = "ripgrep"

[[plugin]]
name = "ruff"
version = "0.5.3"

[[plugin]]
name = "trivy"
drivers = [
  "config",
  "fs-vuln",
]

[[plugin]]
name = "trufflehog"

[[plugin]]
name = "yamllint"

• OS:
  Arch Linux

[brynary]

@dafeder thanks for this report.

How is this typically done with PHPCS when you run it without the Qlty CLI? Are the rule sets specified as command line arguments or a configuration file, for example?

Since the Qlty CLI is executing PHPCS under the hood, anything that PHPCS supports would be supported when running PHPCS via the Qlty CLI.

You can take a look at what it is doing with a command like this:

qlty check --filter=php-codesniffer --no-cache --no-fix --debug --verbose --all

At the bottom of the output you will see a list of JOBS. For each job, there will be a Debug File like .qlty/out/invoke-qyud31.yaml. By opening the Debug File, you can see exactly what was run.

[dafeder]

Thanks for the reply I will try and report back tomorrow. phpcs takes "standard" as either a CLI argument or an option in a project's phpcs.xml config file.

[brynary]

OK, thanks. I noticed we are missing the declaration for phpcs.xml as a config file for PHPCS, so I added that here: #1503

Without the declaration, PHPCS can still use the config file, but we won't expire our cache when the config file changes.

You can get a sense for how we execute PHPCS based on our plugin definition.

If the phpcs.xml file is automatically used by PHPCS then it should be fine. If it needs to be specified on the command line, then we can help get that working as well.

[dafeder]

OK what I should have tried first was just putting phpcs.xml in the project root - seeing the cwd property in the output file made it click that even though it's targeting specific files from the diff, having the xml file in the project root works. I think this is fine, maybe should just be included in the documentation for using with php projects (which is see is still a WIP). It also reflects changes when I make them (probably not a surprise).

Now a new problem: It only has the built-in standards that come with PHPCS out of the box. In codeclimate, a number of additional standards were supported. For my project I would need some way to at least pull in Drupal and DrupalPractice to swap in qlty for codeclimate. There may be, as a workaround, a way to point to an absolute path to a standard in a project's phpcs.xml, I'll do a little testing. But that's not ideal, as obviously that path will change depending on the environment (local vs CI, linux vs mac etc, not to mention when a project is containerized).

[dafeder]

Update - pointing to the local paths for standards does not really work, at least for the Drupal standard which relies on slevomat standard whose autoloader assumptions aren't really compatible with this approach. I'm not sure how in scope this is for where you're going with qlty plugins but it seems like phpcs would need to be built with composer and include all these standards as dependencies. Seeing as the plugin definition is based on phpcs.phar, this might mean maintaining your own phar instead of using phpcs' minimal one? Or else perhaps it would be on the community to publish custom plugins that build phpcs with different combinations on standards/dependencies?

Would it be helpful to resubmit this as a concrete feature request ("Include phpcs standards previously offered by default in CodeClimate")?

[brynary]

Hi @dafeder -- RE: Putting the phpcs.xml file in the root: Glad that works. This is the most common way that configuration files for linters are supported, so that all seems fine.

RE: additional standards. This is something that we are trying to significantly improve with Qlty over Code Climate. Specifically, with Code Climate we had to pre-package a limited set of linter "extensions" (aka standards/configs/plugins) at pre-set versions.

With Qlty, the intention is to allow you to install any standard at any version without needing to wait for us to add it. To do that, we support installing additional PHP packages using Composer files. However, this functionality is better tested for our JavaScript and Ruby plugins, and we may still have a bit more work to do to make everything work completely smoothly with PHP.

I'd like us to take a closer look and make sure this works as expected. Would you be able to please provide a small sample repository which is setup to run PHPCS with your desired standards?

If you can provide an example that works for running phpcs directly without the Qlty CLI, then we should be able to take that and provide a Qlty configuration which gets you the same results (and patch any bugs we may find along the way.)

[dafeder]

Ooops, looks like you were writing this just as I was writing a feature request. Feel free to close that if this thread is the preferred place to keep discussing.

So, a weird thing about phpcs is that it can be installed either at project or global/user level. In my case, I am using CodeClimate on a Drupal project, I never set up phpcs as a dependency in the repo because most of our team sets up their linting tools for Drupal in their own environments, and CodeClimate itself supports Drupal standards out of the box. I'm motivated to get this working so I'll fork our project or set up a new test project and try using this approach. Thanks for your responsiveness and patience.

[dafeder]

So far, having a lot of trouble getting this to work, I think because phpcs is running as a pre-compiled phar so it is not loading project dependencies? Maybe I'm missing something obvious. Here's an example:

https://github.com/GetDKAN/contracts

Check out the branch qlty-test. Run composer install. Run vendor/bin/phpcs. You should get a bunch of linter errors (because we've added the Drupal sniff to phpcs.xml, but this isn't a Drupal project).

Now, run qlty check --filter=php-codesniffer --no-cache --no-fix --debug --verbose --all. You will get an error that the "Drupal" sniff does not exist. The project local phpcs script is using the project's autoloader and bringing in Drupal coder standards as a dependency, but the qlty instance of phpcs is not. Evidence in the debug file, that the command run is /home/dfeder/.qlty/cache/tools/php-codesniffer/3.10.3-08b8f0fd738a/php-codesniffer which is a compiled phar.