lesshint / lesshint Goto Github PK

We use/encourage alphabetizing our property names within our org. Would be great to make this an option.

singleLineProperty is returning a false positive for inline comments.

Valid CSS

.foo {
  background-color: #000;
  color: #000; // black on black
}

Shouldn't error

test.less: line 3, col 5, singleLinePerProperty: Each property should be on it's own line.

Please add support for inline comments

Basic media query code as the one below errors with the message "All property declarations should end with a semicolon" on the second to last semicolon.

@media screen and ( max-width: 768px ){
    @color: red;

    .div {
        color: @color;
    }
}

Tried with this code

div {
    background-image: url( 'http://placekitten.com/g/1200/600' );
}

The only error I get is this

test.less: line 2, col 23, urlQuotes: URLs should enclosed in quotes.

Shouldn't I get an error that the format is incorrect and no error on the quotes?

Do we need any more options? Are we satisfied with the current default value? Any other thoughts?

Current options:

1. absolute
2. relative (default)

Please cast a vote for one of the options or post your other thoughts or suggestions for options.

Do we need any more options? Are we satisfied with the current default value? Any other thoughts?

Current options:
None, do we need any options or is it enough with enabled: true/false?

Please cast a vote for one of the options or post your other thoughts or suggestions for options.

Do we need any more options? Are we satisfied with the current default value? Any other thoughts?

Current options:

1. double
2. single (default)

Please cast a vote for one of the options or post your other thoughts or suggestions for options.

Do we need any more options? Are we satisfied with the current default value? Any other thoughts?

Current options:
None, do we need any options or is it enough with enabled: true/false?

Please cast a vote for one of the options or post your other thoughts or suggestions for options.

Do we need any more options? Are we satisfied with the current default value? Any other thoughts?

Current options:

1. no_space
2. one_space (default)

Please cast a vote for one of the options or post your other thoughts or suggestions for options.

Given the discussion around #43 errors being swallowed, I'd like to raise the question of warnings vs errors. jshint plops every result into an 'errors' object, but has a code on every result that differentiates error from warning. In jshint's case, it has W for warning, I for info, and E for error. I'm not suggesting lesshint follow suit, as I've never been incredibly keen on using single letters for error codes, but it would be a great addition to the project to differentiate.

Consider this lesshint gulp reporter: https://github.com/sagikazarmark/gulp-lesshint-stylish, which is transforming the results and marking everything back from lesshint as a warning.

Ideally everything that lesshint is returning as a result at this moment, sans parse error support, should be a warning. Once parse error support is added, those results should be errors. I'm not sure if info has any use here.

Do we need any more options? Are we satisfied with the current default value? Any other thoughts?

Current options:
None, do we need any options or is it enough with enabled: true/false?

Please cast a vote for one of the options or post your other thoughts or suggestions for options.

Following test was done in v0.7.0

h1 {
  width: 100px;
  height: 100px;
  color: #00f;
  background: #000;
  top:10px;
  left: 1000px;
}

This example Less/CSS file only has the rule finalNewline disabled and it reports the following errors:
test.less: line 7, col 10, hexLength: #00f should be written in the long-form format.
test.less: line 9, col 15, hexLength: #000 should be written in the long-form format.
test.less: line 11, col 7, spaceAfterPropertyColon: Colon after property name should be followed by one space.

As you can see the errors are not correctly guiding me to the correct line number.

Thanks

Do we need any more options? Are we satisfied with the current default value? Any other thoughts?

Current options:
None, do we need any options or is it enough with enabled: true/false?

Please cast a vote for one of the options or post your other thoughts or suggestions for options.

Do we need any more options? Are we satisfied with the current default value? Any other thoughts?

Current options:

1. double
2. single (default)

Please cast a vote for one of the options or post your other thoughts or suggestions for options.

I ran lesshint against this silly tidbit:

.myclass {
  border: none;
  cursor pointer
}

And it produced no output, no errors using default settings. It should have at the least reported on the border: none; line, and should have reported an error in the syntax at cursor pointer. When I change that line to cursor: pointer all is well and I get the error about using 0.

It would appear parsing errors, or syntax errors, are being swallowed.

It would be good for educational purposes to see what the reasoning behind each default is.
Also it will probably spark discussion further down the line which is always a good thing.

The linters are pretty good but the core methods need some more.

Especially lib/lesshint.js and lib/config-loader.js.

Do we need any more options? Are we satisfied with the current default value? Any other thoughts?

Current options:

1. long (default)
2. short

Please cast a vote for one of the options or post your other thoughts or suggestions for options.

Do we need any more options? Are we satisfied with the current default value? Any other thoughts?

Current options:
None, do we need an option to allow missing semicolons on the last property?

Please cast a vote for one of the options or post your other thoughts or suggestions for options.

Other linters/hinters have the ability to ignore linting on a single line via a trailing comment. It would be very useful to have this ability. An example...

My team discourages the use of !important but there are edge cases where it needs to be used. As such, it would be useful to enable importantRule globally, but apply something like // lesshint ignore:line that would ignore linting for a specific line, so that I can allow !important in edge cases (bonus points if we can just ignore the single rule via // lesshint ignore:importantRule).

For code such as this

div{
    property: value;
}

it reports that the error is in column 1.
Shouldn't it be 4?

Do we need any more options? Are we satisfied with the current default value? Any other thoughts?

Current options:

1. no_space (default)
2. one_space

Please cast a vote for one of the options or post your other thoughts or suggestions for options.

Do we need any more options? Are we satisfied with the current default value? Any other thoughts?

Current options:

1. allowWithId (default false)
2. allowWithClass (default false)
3. allowWithAttribute (default false)

Please cast a vote for one of the options or post your other thoughts or suggestions for options.

Do we need any more options? Are we satisfied with the current default value? Any other thoughts?

Current options:
None, do we need any options or is it enough with enabled: true/false?

Please cast a vote for one of the options or post your other thoughts or suggestions for options.

Do we need any more options? Are we satisfied with the current default value? Any other thoughts?

Current options:
None, do we need any options or is it enough with enabled: true/false?

Please cast a vote for one of the options or post your other thoughts or suggestions for options.

spaceBeforeComma returns a false positive with the following LESS file

@var: (4 / 2);

test.less: line 1, col 9, spaceBeforeComma: Commas should not be preceded by any space.

Yet, returns no errors with the following LESS file

@var: (4/ 2);

Please update to allow space before LESS operators.

Do we need any more options? Are we satisfied with the current default value? Any other thoughts?

Current options:

1. no_space (default)
2. one_space

Please cast a vote for one of the options or post your other thoughts or suggestions for options.

Do we need any more options? Are we satisfied with the current default value? Any other thoughts?

Current options:

1. none
2. zero (default)

Please cast a vote for one of the options or post your other thoughts or suggestions for options.

Do we need any more options? Are we satisfied with the current default value? Any other thoughts?

Current options:

1. no_space
2. one_space (default)
3. new_line

Please cast a vote for one of the options or post your other thoughts or suggestions for options.

Do we need any more options? Are we satisfied with the current default value? Any other thoughts?

Current options:

1. exclude_zero
2. include_zero (default)

Please cast a vote for one of the options or post your other thoughts or suggestions for options.

Hate to be this guy but... Should be: Each selector should be on its own line. Possessive form of "its".

Code such as this

.responsive-img( @imgName ) {
    .set-img( 'normal/@{imgName}' );
}

or this

.responsive-img( @imgName ) {
    @media screen and ( max-width: 480px ){
        .set-img( 'mobile-lowres/@{imgName}' );
    }
}

produces the "There shouldn't be any empty rules present" linting error.

Do we need any more options? Are we satisfied with the current default value? Any other thoughts?

Current options:

1. lowercase (default)
2. uppercase

Please cast a vote for one of the options or post your other thoughts or suggestions for options.

Do we need any more options? Are we satisfied with the current default value? Any other thoughts?

Current options:

1. no_space
2. one_space (default)

Please cast a vote for one of the options or post your other thoughts or suggestions for options.

Do we need any more options? Are we satisfied with the current default value? Any other thoughts?

Current options:
global: [] Array of allowed units (currently all CSS units)
properties: {} Object with unit overrides for specific properties

Please cast a vote for one of the options or post your other thoughts or suggestions for options.

Do we need any more options? Are we satisfied with the current default value? Any other thoughts?

Current options:
None, do we need any options or is it enough with enabled: true/false?

Please cast a vote for one of the options or post your other thoughts or suggestions for options.

This seems to be intended but wouldn't it be a bit more helpful if it just produces a warning and uses defaults instead?

Do we need any more options? Are we satisfied with the current default value? Any other thoughts?

Current options:
None, do we need any options or is it enough with enabled: true/false?

Please cast a vote for one of the options or post your other thoughts or suggestions for options.

Do we need any more options? Are we satisfied with the current default value? Any other thoughts?

Current options:
None, do we need any options or is it enough with enabled: true/false?

Please cast a vote for one of the options or post your other thoughts or suggestions for options.

Do we need any more options? Are we satisfied with the current default value? Any other thoughts?

Current options:

1. no_space (default)
2. one_space

Please cast a vote for one of the options or post your other thoughts or suggestions for options.

We've decided to move forward with forking lesshint and contributing to it, but wanted to get on the same page with how you guys are using branches.

It appears from the request to PR to the 0.8.1 branch, that you're developing off of separate branches before pushing to master. So that's our first question - Why? Typically branches like that are used for features and then PR'd to master. Or a branch is marked as 'development' and used by primary maintainers/contributors to do out-of-track-next-major-version work. But PRs from forks are almost always made to master.

It also looks like you're creating a branch to work on a patch release, which is not something we've seen done before. We've seen minor and major branches before, but never for a patch release (as following semver, patch releases are for bugfixes only and should follow the primary track).

We follow semver pretty closely in our org, and for ease of use and org-wide contribution, it'd be great to get on the same page. I'm certainly not suggesting that you adopt any of our practices, merely requesting some discussion around adopting some more widely accepted standards in this area.

Here's and example that validates, which it shouldn't

@color: #fff;

div {
    color: @color;
}

Do we need any more options? Are we satisfied with the current default value? Any other thoughts?

Current options:
Regexp for allowed comments.

Please cast a vote for one of the options or post your other thoughts or suggestions for options.

Do we need any more options? Are we satisfied with the current default value? Any other thoughts?

Current options:

1. no_space (default)
2. one_space

Please cast a vote for one of the options or post your other thoughts or suggestions for options.

My team uses 4 spaces per indentation. It would be nice to have a linter to check that indentation is correct. Something along the lines of the following (with suggested defaults):

validateIndentation

syntax

"validateIndentation": {
  "enabled": true,
  "style": "spaces",
  "quantity": 4
}

options

style (string)

• spaces (default)
• tabs

quantity (integer) number of spaces/tabs per indentation

• 2 (default)
• user defined value

When running into an linting error the linter will stop after every file that has an error.

Shouldn't it lint all files or is this by design?

Do we need any more options? Are we satisfied with the current default value? Any other thoughts?

Current options:

1. keep_unit
2. no_unit (default)

Please cast a vote for one of the options or post your other thoughts or suggestions for options.

Do we need any more options? Are we satisfied with the current default value? Any other thoughts?

Current options:

1. exclude_zero (default)
2. include_zero

Please cast a vote for one of the options or post your other thoughts or suggestions for options.

Do we need any more options? Are we satisfied with the current default value? Any other thoughts?

Current options:
exclude: array of files to exclude
filenameExtension: true/false (default false)
leadingUnderscore: true/false (default false)

Please cast a vote for one of the options or post your other thoughts or suggestions for options.