Gathering detailed insights and metrics for stylelint-declaration-use-variable
Gathering detailed insights and metrics for stylelint-declaration-use-variable
Gathering detailed insights and metrics for stylelint-declaration-use-variable
Gathering detailed insights and metrics for stylelint-declaration-use-variable
A stylelint custom rule to check the use of scss variable on declaration.
npm install stylelint-declaration-use-variable
Module System
Min. Node Version
Typescript Support
Node Version
NPM Version
82 Stars
72 Commits
17 Forks
1 Watching
4 Branches
8 Contributors
Updated on 17 Jun 2024
JavaScript (100%)
Cumulative downloads
Total Downloads
Last day
-16.2%
9,373
Compared to previous day
Last week
-2.1%
55,467
Compared to previous week
Last month
8.8%
237,194
Compared to previous month
Last year
-11.2%
2,211,107
Compared to previous year
1
3
:warning: This project is not actively maintained. Please use stylelint-declaration-strict-value :warning:
A stylelint plugin that check the use of scss, less or custom css variable on declaration. Either used with '$', map-get(), '@' or 'var(--var-name)'.
npm install stylelint-declaration-use-variable
Be warned: v0.2.0+ is only compatible with stylelint v3+. For earlier version of stylelint, use earlier versions of this.
Add it to your stylelint config plugins
array, then add "declaration-use-variable"
to your rules,
specifying the property for which you want to check the usage of variable.
Like so:
1// .stylelintrc 2{ 3 "plugins": [ 4 "stylelint-declaration-use-variable" 5 ], 6 "rules": { 7 // ... 8 "sh-waqar/declaration-use-variable": "color", 9 // ... 10 } 11}
Multiple properties can be watched by passing them inside array. Regex can also be used inside arrays.
1// .stylelintrc 2"rules": { 3 // ... 4 "sh-waqar/declaration-use-variable": [["/color/", "z-index", "font-size"]], 5 // ... 6}
Passing a regex will watch the variable usage for all matching properties. This rule will match all CSS properties while ignoring Sass and Less variables.
1// .stylelintrc 2"rules": { 3 // ... 4 "sh-waqar/declaration-use-variable": "/color/", 5 // ... 6}
Passing ignoreValues
option, you can accept values which are exact same string or matched by Regex
1// .stylelintrc 2"rules": { 3 // ... 4 "sh-waqar/declaration-use-variable": [["/color/", "font-size", { ignoreValues: ["transparent", "inherit", "/regexForspecialFunc/"] }]], 5 // ... 6}
Preprocessers like scss, less uses variables to make the code clean, maintainable and reusable. But since developers are lazy they might get a chance to miss the use of variables in styling code and that kinda sucks.
1$some-cool-color: #efefef; 2 3.foo { 4 display: inline-block; 5 text-align: center; 6 color: #efefef; // Wait a min! there should be a variable. 7}
Scss variables using '$' notation and map-get are supported
1// Simple variables 2$some-cool-color: #efefef; 3$some-integer: 123; 4$some-pixels: 4px; 5 6color: $some-cool-color; 7 8// Using map-get 9$cool-colors: ( 10 blue: #3ea1ec, 11 red: #eb5745, 12); 13 14color: map-get($cool-colors, blue); 15
If you plan to level-up the usage of your variables by the usage of fancy color-functions - you can!
Instead of a direct variable usage like this:
1$white: #fff; 2 3.foo { 4 color: $white; 5}
You could also do things like:
1.foo { 2 color: color($white shade(10%)); 3}
This will still be seen as a valid code by the plugin. As a side-note, it doesn't matter what kind of variable-syntax
you are using in the color function itself - if the line starts with color(
then it is seen as valid.
If you contribute and wonder about the check for
color(
- it couldn't be done via regex because not only values will be passed to the plugin, but also property names. For some reason, the plugin just dies if you start extending the regex to look for "color". So it must be done via extra-if-check.
No vulnerabilities found.
Reason
no binaries found in the repo
Reason
license file detected
Details
Reason
Found 5/10 approved changesets -- score normalized to 5
Reason
0 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 0
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
security policy file not detected
Details
Reason
project is not fuzzed
Details
Reason
branch protection not enabled on development/release branches
Details
Reason
SAST tool is not run on all commits -- score normalized to 0
Details
Reason
14 existing vulnerabilities detected
Details
Score
Last Scanned on 2024-11-18
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn More