CSS vs. POSTCSS sources

[szwoelf]

We use different tools for testing code quality. Most of these tools use the file extension to determine the file type. Unfortunately the "*.m.css" files are post css files and sometimes the scanners fail.

Would it be possible to change the file extension of css to "pcss" so that IDEs, static code analysis tools (...) can recognize the file type by the extension?

(I hope that this issue is not completely wrong here - sorry if ...)

[tomdye]

I have replied to this is gitter but pasting response here for reference:

We’re not using any particularly agressive postcss plugins, only css-next and imports to enable future css syntax much like when writing esnext js and running it through babel. The m in the naming is to differentiate between if the file is to be processed as a css-module or not. We chose to stay clear of pcss extensions as they are technology specific and we may not use postcss in the future when the css-next functions we are using are supported by browsers.

If you are able to set your code quality tools to avoid .pcss files then are you not able to do the same for .m.css files?
Regarding IDE plugins etc, it is possible to add .m.css to the extensions the plugins use, I myself have done this is vscode. As specified above however, the goal is to stay as close to css and future css syntax as possible so the IDE plugin does not appear to be of much use to me personally.

[szwoelf]

(Thx for the response and your suggestions, answers on Gitter.)
Unfortunately SonarQube (which we are to be used now ...) has only include filters. The include is *.css - so what to do?

Unfortunately we were coming from the other side - not CSS modules at all and we started with a predefined SCSS design. So we additionally used nesting (...) and other features in the .m.css.
Finally we came up with the decision to stop validating CSS at all.

I deeply respect your opinion on that - but we thought that it is meant to be *.m.pcss just because PostCSS features have been working .... :-/

Thx in advance.

[dylans]

@szwoelf @lucidlemon in searching for an answer for this, could you tell us which CSS plugins for SonarQube you are using? Because nesting in PostCSS follows the CSS.Next syntax for nesting, we're wondering if the SonarQube CSS plugin should be fixed? What other features in .m.css is SonarQube complaining about from PostCSS? Also are you using any PostCSS features that are not part of CSS.Next?

[dylans]

Unfortunately SonarQube (which we are to be used now ...) has only include filters.

Also wondering if it's the plugin that is struggling with excludes, as I think SonarQube does support exclusions as per https://docs.sonarqube.org/display/SONAR/Narrowing+the+Focus .

[szwoelf]

Thank you very much for the hint.

I don't want to whine too much - but our version of SonarQube only supports a Comma-separated list of suffixes for CSS files to analyze. - exclude filters - also on the project didn't work (anymore). So I skipped the CSS analyze because of too much noise by configuring the extension: nocssbecausecssispostcss ;-) ....

Anyway there is currently no PostCSS support in SonarQube. As you stated in our meeting ... "let's see what the future brings".

[szwoelf]

@dylans the worst thing was the nesting syntax of PostCSS that broke the parser in SonarQube. This rendered the checks useless. In this case we couldn't even change the priority of some rule from whatever to 'minor'.

[dylans]

Ok. The one thing worth noting is that it’s not PostCSS’ syntax, but rather the CSS Nesting specification syntax. So this means that SonarQube needs to get an update to support nesting. Are you locked on a particular version of SonarQube? I can reach out to their team and see if they have a fix planned for this.

[tomdye]

Closing this as I do not believe it to be relevant anymore