[buddypress-trac] [BuddyPress Trac] #7028: Use stylelint to lint SCSS & CSS replacing Ruby gem `scss_lint`

[buddypress-trac]

#7028: Use stylelint to lint SCSS & CSS replacing Ruby gem `scss_lint`
---------------------------------------+-----------------------------
 Reporter:  netweb                     |       Owner:
     Type:  defect (bug)               |      Status:  new
 Priority:  normal                     |   Milestone:  Future Release
Component:  Tools - Build Process      |     Version:  2.3.0
 Severity:  normal                     |  Resolution:
 Keywords:  needs-patch needs-refresh  |
---------------------------------------+-----------------------------

Comment (by netweb):

 Replying to [comment:3 hnla]:
 > There may be a few things to consider before committing.

 Indeed, there are quite a few things needed to consider and go through
 before committing :)


 > We seem to induce new errors that passed before under scsslint.

 The goal here is to adhere to WordPress' CSS coding standards, which
 includes CSS. stylelint is a far more powerful and granular than that of
 scss_lint, hence more fine grained issues can be checked using stylelint
 that scss_lint.

 So as much as scss_lint has served BP well up until now there are CSS
 issues that do not match the coding standards because either scss_lint had
 no option to detect those issues or the option was not enabled.


 > Why do those scss lint commands need to be in true css comment syntax as
 in a scss file that means they are compiled pointlessly to the real
 stylefile, with scsslint I used their rules but in  forward slash escapes
 '//'

 Where exactly, can you give me an example of where I missed that? My quick
 check of the [attachment:7028.patch] shows the double slash `//` comments
 untouched and we should continue to use both comment formats where
 applicable so that comments we want compiled and to appear in the compiled
 CSS using `/*` and to not be compiled with `//`


 > We need to be careful about placing restrictions on how coders use
 things like shorthand properties they can be an arcane process requiring
 nuanced use.

 Yes, the [https://make.wordpress.org/core/handbook/best-practices/coding-
 standards/css/#properties coding standards] state: '' "Use shorthand
 (except when overriding styles) for background, border, font, list-style,
 margin, and padding values as much as possible. (For a shorthand
 reference, see CSS Shorthand."''

 The stylelint rule
 [https://github.com/stylelint/stylelint/tree/master/src/rules/shorthand-
 property-no-redundant-values shorthand-property-no-redundant-values] and
 [https://github.com/stylelint/stylelint/tree/master/src/rules/declaration-
 block-no-shorthand-property-overrides declaration-block-no-shorthand-
 property-overrides] rules handle this. Is there a case where this was
 missed in the CSS?


 ''The new line issues I'll come back to in another comment to avoid
 cluttering this comment with a huge wall of text ;)''

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/7028#comment:5>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac