Documentation Index
Fetch the complete documentation index at: https://docs.qlty.sh/llms.txt
Use this file to discover all available pages before exploring further.
Plugin errors
A plugin error indicates that a plugin exited with a status code that is interpretted as an error. This can occur for a number of different reasons. For example, some linters will crash if they attempt to analyze files with invalid syntax.Some linters exit with a non-zero code when they find issues. Qlty treats these exit codes as
success to differentiate the case where a plugin ran successfully identified issues vs. a
crash or unexpected failure.
Verbose and debug output
Typically the first step to investigating a plugin error is to re-run the plugin with verbose or debug output enabled. Here is an example:--debug option will increase the amount of detail in the logs going to .qlty/logs/qlty-cli.*. You can tail this log as you run the CLI to watch for issues with tail -f .qlty/logs/qlty-cli.*.
The --verbose option will cause the CLI to print a summary of every invocation (execution) of the plugin from the run. The full details of each invocation are recorded in an output file saved to the .qlty/out/ directory. Here is an example:
maxLines=10
Could not find "[package-name]" (Missing plugin extension)
A common error is that a plugin may be missing an extension references in its configuration. For example:
@blueprintjs/stylelint-plugin. The reason that this would happen is because the Qlty CLI installs static analysis tools into sandboxes in order to create conssitent, reporducible results whereever it is run.
When an erorr like this occurs, you will generally find that the references package (in this case, @blueprintjs/stylelint-plugin) is included in the project’s package.json file. By default, we do not install the packages in the package.json file when we run analysis.
There are a three ways to fix this:
Option 1: Use the `extra_packages` option
Option 1: Use the `extra_packages` option
Specify the This tells Qlty to install
extra_packages option for the plugin in qlty.toml. Any listed packages will be installed into the tool’s sandbox making them available. Here is an example:stylelint-config-standard-scss@11.0.0 into the sandbox for the stylelint plugin before running. This syntax works for simple cases and has the benefit of keeping the dependency declaration directly inline with the plugin configuration.Option 2: Point the `package_file` option at your existing package.json
Option 2: Point the `package_file` option at your existing package.json
This will cause Qlty to install all of the packages in the If you are using a lot of extensions for your static analysis tools, this is a good way to get up and running quickly. The primary disadvantage is that all of the dependencies need to be installed before static analysis can be run, which can slow things down.
package.json file into the sandbox for the plugin. Here is an example:Option 3: Create a new package.json limited to static analysis tools
Option 3: Create a new package.json limited to static analysis tools
This allows you to install all the extensions you need quickly and can allow you to de-clutter your main
package.json file. Here is an example:Could not find "[config file].[json]" (Missing configuration file)
If you have a static analysis configuration file that is not using one of the tool’s standard configuration filenames, Qlty needs to know about it. Otherwise, you will see errors like this:
stylelintrc.shared.json. To do this, you need to override the definition of the Stylelint plugin to include all of the configuration file names you use in your project.
For example, you can add this towards the top of your .qlty/qlty.toml file: