simenb/stylint

Improve your Stylus code with Stylint

stylint's Issues

Line breaks in complex selectors using `&` warn of invalid property

I use the & (parent reference) in Stylus nesting to simplify my CSS naming convention. When creating complex selectors (like styling hyperlinks for :link, :visited, :active, etc.) and using the parent reference, AND using line breaks, Stylint warns of an invalid property when valid: true.

property.styl

.block1 {
    // Passes just fine
    &--link, &--link:link {
        color: #000;
    }
}

.block2 {
    // Throws warning
    &--link,
    &--link:link {
        color: #000;
    }
}

property.json

{
    "alphabetical": true,
    "borderNone": true,
    "brackets": false,
    "colons": false,
    "colors": false,
    "commaSpace": true,
    "commentSpace": false,
    "cssLiteral": false,
    "depthLimit": false,
    "duplicates": true,
    "efficient": true,
    "enforceBlockStyle": false,
    "enforceVarStyle": false,
    "extendPref": false,
    "globalDupe": false,
    "indentSpaces": 4,
    "leadingZero": true,
    "maxWarnings": 10,
    "maxWarningsKill": false,
    "mixed": false,
    "namingConvention": false,
    "parenSpace": false,
    "placeholders": true,
    "semicolons": false,
    "universal": true,
    "valid": true,
    "whitespace": true,
    "zeroUnits": true,
    "zIndexDuplicates": false,
    "zIndexNormalize": false
}

Warning:

Warning:  property is not valid
File: property.styl
Line: 10: &--link,

duplicateCheck looks buggy

Hi,
It seems like duplicateCheck is a bit buggy.

I get a warning for the following code:

.foo {
  .bar {
    color: red;
  }
}

Warning: duplicate property or selector, consider merging
File: ./app/assets/stylus/fubar.styl
Line: 5: }

Setting it to false has no effect either, same warning regardless of settings.

...
"duplicates": false,
"globalDupe": false,
...

Interpolation confuses namingConvention setting sometimes

I've mostly tested this with the "lowercase-dash" setting of the namingConvention configuration, but I think other settings are affected, too.

This is a frankly bizarre case, probably something to do with a regular expression, but it just so happens to be a pattern that I use over and over in my Stylus files. Hopefully I've provided enough examples here to help you debug it.

lowercase-dash.styl

$class-name = error
$dark-red = maroon

.{$class-name} {
    color: $dark-red;
}

lowercase-dash.json

{
    "alphabetical": true,
    "borderNone": true,
    "brackets": false,
    "colons": false,
    "colors": false,
    "commaSpace": true,
    "commentSpace": false,
    "cssLiteral": false,
    "depthLimit": false,
    "duplicates": true,
    "efficient": true,
    "enforceVarStyle": false,
    "enforceBlockStyle": false,
    "extendPref": false,
    "globalDupe": false,
    "indentSpaces": 4,
    "leadingZero": true,
    "maxWarnings": 10,
    "maxWarningsKill": false,
    "mixed": false,
    "namingConvention": "lowercase-dash",
    "parenSpace": false,
    "placeholders": true,
    "semicolons": false,
    "Whitespace": true,
    "universal": true,
    "valid": false,
    "zeroUnits": true,
    "zIndexDuplicates": false,
    "zIndexNormalize": false
}

Run this command:

$ stylint lowercase-dash.styl -c lowercase-dash.json

The output is:

Warning:  preferred naming convention is lowercase-dash
File: lowercase-dash.styl
Line: 4: .{$class-name} {

Ready for the weird part? The following variations of the styl file pass just fine:

Interpolation happens at the beginning of the line:

$class-name = .error
$dark-red = maroon

{$class-name} {
    color: $dark-red;
}

A space (or multiple spaces) begin the line:

$class-name = error
$dark-red = maroon

 .{$class-name} {
    color: $dark-red;
}

We have more characters after the period (as long as it follows the lowercase-dash convention):

$class-name = error
$dark-red = maroon

.block-{$class-name} {
    color: $dark-red;
}

Not:

$class-name = error
$dark-red = maroon

.block_{$class-name} {
    color: $dark-red;
}

These same issues seem to apply to using the hash. The following fails:

$class-name = error
$dark-red = maroon

#{$class-name} {
    color: $dark-red;
}

But this works:

$class-name = error
$dark-red = maroon

#block-{$class-name} {
    color: $dark-red;
}

Other characters seem to work fine, too.

Attributes:

$class-name = error
$dark-red = maroon

[{$class-name}] {
    color: $dark-red;
}

Psuedo-class:

$class-name = error
$dark-red = maroon

:{$class-name} {
    color: $dark-red;
}

Psuedo-element:

$class-name = error
$dark-red = maroon

::{$class-name} {
    color: $dark-red;
}

And there are probably more examples. Hopefully this is enough to help you narrow down on the issue. Let me know how else I can help.

Hashes trigger unnecessary colon warning

Colons are necessary in hashes and shouldn't set off a warning

check for trailing whitespace

Leading Zero check throwing false positives

width 40.9473684211%

should be considered valid

"pointer-events" property is not considered valid

I get a warning when using the pointer-events property in CSS class:

.my-class
    &:after
      pointer-events: none

Config:

{
  "alphabetical": true,
  "borderNone": true,
  "brackets": false,
  "colons": false,
  "colors": false,
  "commaSpace": true,
  "commentSpace": true,
  "cssLiteral": false,
  "depthLimit": 3,
  "duplicates": true,
  "efficient": true,
  "enforceBlockStyle": false,
  "enforceVarStyle": true,
  "extendPref": "@extend",
  "globalDupe": true,
  "indentSpaces": 2,
  "leadingZero": true,
  "maxWarnings": 10,
  "maxWarningsKill": false,
  "mixed": true,
  "namingConvention": "lowercase-dash",
  "parenSpace": false,
  "placeholders": true,
  "semicolons": false,
  "universal": true,
  "valid": true,
  "whitespace": true,
  "zeroUnits": true,
  "zIndexDuplicates": false,
  "zIndexNormalize": false
}

Output:

Warning:  property is not valid
File: path/to/file.styl
Line: 163: pointer-events: none; 

check for valid css attributes / properties

this should also function like a reserved word list, preventing you from setting var names like padding or margin

namingConvention strictness level ?

this was brought up in another issue, that you won't always have full control over class names or ids.

in this case, namingConvention will throw lots of warnings at you that are out of your control

we could create a config settings that allows to toggle the breadth of the namingConvention option.

if namingConventionStrict: true is set, then namingConvention will target classes and ids as well as variables. if set to false, then it will only care about variables

allow configurable indent level and check for it

Setting variable to a font stack can throw false namingConvention warning

When using a variable to define a font stack, the way the fonts are named in the list can throw false namingConvention warnings.

fontname.styl

// No warning
$font-stack = sans-serif

// No warning
$font-stack = helvetica, sans-serif

// Warning
$font-stack = Helvetica, sans-serif

fontname.json

{
    "alphabetical": true,
    "borderNone": true,
    "brackets": false,
    "colons": false,
    "colors": false,
    "commaSpace": true,
    "commentSpace": false,
    "cssLiteral": false,
    "depthLimit": false,
    "duplicates": false,
    "efficient": true,
    "enforceVarStyle": false,
    "enforceBlockStyle": false,
    "extendPref": false,
    "globalDupe": false,
    "indentSpaces": 4,
    "leadingZero": true,
    "maxWarnings": 10,
    "maxWarningsKill": false,
    "mixed": false,
    "namingConvention": "lowercase-dash",
    "parenSpace": false,
    "placeholders": true,
    "semicolons": false,
    "Whitespace": true,
    "universal": true,
    "valid": false,
    "zeroUnits": true,
    "zIndexDuplicates": false,
    "zIndexNormalize": false
}

Results:

Warning:  preferred naming convention is lowercase-dash
File: fontname.styl
Line: 8: $font-stack = Helvetica, sans-serif

If I change the namingConvention to lowercase_underscore and change my variable name to $font_stack, every line throws a warning. I haven't tested the other namingConvention settings.

Linter is linting comments

Warnings should not be triggered by comments, unless the warning specifically deals with comments (see the no space after line comments warning).

Feature request: Add support for ´namingConvention: BEM´

Would be great if there were to be support for BEM as a naming convention in Stylint.

^[a-z]([-]?[a-z0-9]+)*(__[a-z0-9]([-]?[a-z0-9]+)*)?((_[a-z0-9]([-]?[a-z0-9]+)*){2})?$

Pattern source sds/scss-lint#254 (comment)

mixinSpace should eventually just be parenSpace

the space check should extend to if blocks or really anywhere where ( ) is used

Missing documentation for "placeholders" config option

I can't tell what the placeholders option does. Looking at the code, the placeholder.js file almost looks like a duplicate of an old version of the extends.js check. There is also no explanation of the placeholders config option in the README.md.

speed up start up time

now that we're pulling in 39 modules, there is a small but noticeable delay before the linter runs

z-indexr

parse stylus and recommend new z-index values using a configurable base unit

1, 5, 10, whatever

var declarations inside functions throw false positives

example:

col-width(index)
    first-value = floor((100% / $columns) * index)
    second-value = unit( round( ($gutter-med / ($columns / index) - $gutter-med) - 1, 3), 'px')
    final-value = s('calc(%s + %s)', first-value, second-value)
    return final-value

should throw a $ is need error, which is correct

col-width($index)
    $first-value = floor((100% / $columns) * $index)
    $second-value = unit( round( ($gutter-med / ($columns / $index) - $gutter-med) - 1, 3), 'px')
    $final-value = s('calc(%s + %s)', first-value, second-value)
    return $final-value

should resolve the error, but does not

Gulp Wrapper

create an easy to use (pipable) wrapper for gulp

Respect exit code

Please respect the UNIX exit code philosophy, zero on success and greater than zero on error.

It appears to me that the program always exits with zero, looking at https://github.com/rossPatton/stylint/blob/master/src/done.js it should be easy to implement with the caveat that watch mode would need to be tested to ignore calling process.exit.

universal is too sensitive

This throws a warning:

fubarCalcFunction( $width, $height ) {
  return ( $width*$height );
}

This does not:

fubarCalcFunction( $width, $height ) {
  return ( $width * $height );
}

check for alphabetical ordering of properties

encorce names-like-this or namesLikeThis in the config

Asterisk in `content` property generates warning about universal selector

When the universal: true flag is set, asterisks in content of a content property throw a false warning.

universal.styl

input.required::after {
    content: "*";
}

universal.json

{
    "alphabetical": true,
    "borderNone": true,
    "brackets": false,
    "colons": false,
    "colors": false,
    "commaSpace": true,
    "commentSpace": false,
    "cssLiteral": false,
    "depthLimit": false,
    "duplicates": true,
    "efficient": true,
    "enforceBlockStyle": false,
    "enforceVarStyle": false,
    "extendPref": false,
    "globalDupe": false,
    "indentSpaces": 4,
    "leadingZero": true,
    "maxWarnings": 10,
    "maxWarningsKill": false,
    "mixed": false,
    "namingConvention": false,
    "parenSpace": false,
    "placeholders": true,
    "semicolons": false,
    "universal": true,
    "valid": false,
    "whitespace": true,
    "zeroUnits": true,
    "zIndexDuplicates": false,
    "zIndexNormalize": false
}

Result:

Warning:  * selector is slow. Consider a different selector.
File: universal.styl
Line: 2: content: "*";

This warning occurs even if the asterisk is not the only content, for instance content: "Required*".

`duplicates: true` doesn't play nicely with listing multiple selectors on newlines without commas

If I write

foo
bar
  height: 10px

foo
  color: red

It thinks that I'm selecting foo twice.

Stylint works perfectly if I write (notice the comma after the first foo):

foo,
bar
  height: 10px

foo
  color: red

check for mixed spaces and tabs

jscs style config

now that features are finally being ironed out a bit, we need to allow for a wider range of config options for a lot of the checks

example: instead of semicolons: bool, it should be semicolons: 'always', 'never', false

where:
'always' === force use of semicolons
'never' === force absence of semicolons
false === don't check for this

Unicode emoji in "done" logs render as empty boxes on Windows

I honestly had no idea that you *nix users get a 👍 when things are all clear. On Windows, there's just an empty box.

This is what I see on Windows:

I'll submit a pull request that I think can address this, although I'm open to ideas on how to do it in a better way. I'll explain more in the PR.

Quotation style enforcement?

A feature that I like from JSHint is the ability to enforce quotation types. I try to enforce double quotes in my CSS/Stylus and single quotes in my JavaScript. Is that something others would find valuable in Stylint?

That said, it looks like JSHint is moving away from enforcing this rule altogether: http://jshint.com/docs/options/#quotmark

naming convention checker is too sensitive

remove lockdown

seriously fucked this up -> remove lockdown

Warns "Warning: duplicate property or selector, consider merging" for `@require` statements

When the "duplicates" flag is set to true, multiple @require statements are warned as being duplicates even if they require different stylus files. To recreate the issue, create the following files and run the command at the bottom.

base.styl

body {
    color: red;
}

otherfile.styl

p {
    padding: 4em;
}

site.styl

@require 'base';
@require 'otherfile';

config.json

{
    "alphabetical": false,
    "borderNone": false,
    "brackets": false,
    "colons": false,
    "commaSpace": false,
    "commentSpace": false,
    "cssLiteral": false,
    "depthLimit": false,
    "duplicates": true,
    "efficient": false,
    "enforceBlockStyle": false,
    "enforceVarStyle": false,
    "extendPref": false,
    "globalDupe": false,
    "indentSpaces": false,
    "leadingZero": false,
    "maxWarnings": false,
    "maxWarningsKill": false,
    "mixed": false,
    "namingConvention": false,
    "parenSpace": false,
    "placeholders": false,
    "semicolons": false,
    "Whitespace": false,
    "universal": false,
    "valid": false,
    "zeroUnits": false,
    "zIndexDuplicates": false,
    "zIndexNormalize": false
}

Then execute this:

$ stylint site.styl -c config.json
Warning:  duplicate property or selector, consider merging
File: site.styl
Line: 2: @require 'otherfile';

$ before var checker is throwing false positives when vars used inside if blocks

check for duplicate properties / selectors

Alphabetical Check throwing false positives

really should have tested this better

alphabetical check works... but it should be able to distinguish blocks, extends, and mixins. As in, it shouldn't throw errors if mixins aren't alphabetically sorted with properties

mixed spaces and tabs seems too sensitive

efficient check no longer working?

bracket check shouldnt trigger when interpolated vars used

check for unnecessary brackets

prohibit use of brackets outside of hashes ( or force them, i guess )

´stylint -v´ returns my app version, not Stylint module version

This is a minor issue, but I just want you to know about it. :)

I'm running Stylint local (using Gulp) instead of global, and when I'm doing a versions check I get the version of my app instead of the version of Stylint.

async all the things

ive been sloppy

write tests! write tests! write tests!

Watch apparently crashes when no filename or dir passed in

Warns "Warning: property is not valid" for `@require` statements

When the "valid" flag is set to true, @require statements are warned as being invalid properties. To recreate the issue, create the following files and run the command at the bottom.

base.styl

body {
    color: red;
}

site.styl

@require 'base';

config.json

{
    "alphabetical": false,
    "borderNone": false,
    "brackets": false,
    "colons": false,
    "commaSpace": false,
    "commentSpace": false,
    "cssLiteral": false,
    "depthLimit": false,
    "duplicates": false,
    "efficient": false,
    "enforceBlockStyle": false,
    "enforceVarStyle": false,
    "extendPref": false,
    "globalDupe": false,
    "indentSpaces": false,
    "leadingZero": false,
    "maxWarnings": false,
    "maxWarningsKill": false,
    "mixed": false,
    "namingConvention": false,
    "parenSpace": false,
    "placeholders": false,
    "semicolons": false,
    "Whitespace": false,
    "universal": false,
    "valid": true,
    "zeroUnits": false,
    "zIndexDuplicates": false,
    "zIndexNormalize": false
}

Then execute this:

$ stylint site.styl -c config.json
Warning:  property is not valid
File: site.styl
Line: 1: @require 'base';

Grunt Wrapper

create an easy to use wrapper for grunt

$var checker should work in blocks or mixins

in order to make this work will need to get valid working, then check against that.

Lowercased names throw false warning for several namingConventions

Stylint currently throws a warning if your name is simply lowercased. I've seen this issue whether you use camelCase, lowercase_underscore or lowercase-dash as your namingConvention.

shorties.styl

$color = black

.select {
    border: 1px solid $color;
}

shorties.json

{
    "alphabetical": true,
    "borderNone": true,
    "brackets": false,
    "colons": false,
    "colors": false,
    "commaSpace": true,
    "commentSpace": false,
    "cssLiteral": false,
    "depthLimit": false,
    "duplicates": false,
    "efficient": true,
    "enforceVarStyle": false,
    "enforceBlockStyle": false,
    "extendPref": false,
    "globalDupe": false,
    "indentSpaces": 4,
    "leadingZero": true,
    "maxWarnings": 10,
    "maxWarningsKill": false,
    "mixed": false,
    "namingConvention": "lowercase-dash",
    "parenSpace": false,
    "placeholders": true,
    "semicolons": false,
    "Whitespace": true,
    "universal": true,
    "valid": false,
    "zeroUnits": true,
    "zIndexDuplicates": false,
    "zIndexNormalize": false
}

Output:

Warning:  preferred naming convention is lowercase-dash
File: ../temp-stylus/shorties.styl
Line: 1: $color = black

Warning:  preferred naming convention is lowercase-dash
File: ../temp-stylus/shorties.styl
Line: 3: .select {

Notice that the error throws on the variable $color and the class in the selector. I know namingConvention enforces rules on both.

border 0 is preferred over border none

Valid attribute selectors flagged as invalid properties

It seems attribute presence and value selectors are being flagged as invalid properties. For instance:

a[href]
  outline: none;

when run through stylint generates:

Warning:  property is not valid
File: test.styl
Line: 1: a[href]

Make Documentation Pretty