The HTML sensor provides two configuration properties (sonar.html.file.suffixes and sonar.jsp.file.suffixes), but it also scans files with the following extensions: {“php”, “php3”, “php4”, “php5”, “phtml”, “inc”, “vue”}
The latter list is a constant in the code, and it’s not possible to override at run-time:
In our use case, we want to scan “.inc” files with a custom plugin, and the only way to disable HTML issues there is by disabling the rules in the project profile. But it would be nice if there was a runtime property to configure these “other suffixes”.
Hi, thanks for your reply. At our company we use the “.inc” extension for a custom templating language (it’s not PHP) where we don’t want SonarQube’s HTML rules. It’s true it contains fragments of HTML but we wanted to avoid running the sensor for issues we aren’t interested in at the moment (even if the rules are disabled, the sensor will do some processing on those files).
I mean, if all plugins offer properties to configure file extensions. Why does the HTML sensor force scanning on a hard-coded set of them?
The file extensions you configure are the ones you say that language owns exclusively. For instance, between T-SQL and PL/SQL, which language owns the .sql files in a project? The answer can’t be both. So that’s what you’re configuring when you configure those extensions. What you have in some situations though is additional, non-exclusive analysis such as what you’ve observed on .inc files. When HTML rules are run on those files, they don’t block other languages from ownership, so we’ve never seen the need to make this configurable.
What you can do here is Ignore Issues on Multiple Criteria, which would let you block all HTML rules from your .inc files. I don’t guarantee the sensor won’t process the files, but at least the issues will be suppressed without forcing you to turn the rules off altogether.