schorfes / node-lintspaces

A validator for checking different kinds of whitespaces in your files.

Hey! 👨‍💻

node-lintspaces's Issues

Edge cases where spaces are acceptable for indentation in tab indented files

Very cool module - already found loads of mistakes in my own code. Would love to do more with it but in order to do that there are some cases it's catching that are arguably not mistakes - and it would be really handy to be able to allow some usage of spaces for indentation on files indented by tabs, for example in doc block comments:-

/**
 * Test
 *
 * @author Matt Andrews
 */

module.exports = function() {
    alert("Hi');
};

This will give the follow errors when linting with tabs:-

{  
   "./test.js":{  
      "2":[  
         {  
            "line":2,
            "code":"INDENTATION_TABS",
            "type":"warning",
            "message":"Unexpected spaces found."
         }
      ],
      "3":[  
         {  
            "line":3,
            "code":"INDENTATION_TABS",
            "type":"warning",
            "message":"Unexpected spaces found."
         }
      ],
      "4":[  
         {  
            "line":4,
            "code":"INDENTATION_TABS",
            "type":"warning",
            "message":"Unexpected spaces found."
         }
      ],
      "5":[  
         {  
            "line":5,
            "code":"INDENTATION_TABS",
            "type":"warning",
            "message":"Unexpected spaces found."
         }
      ]
   }
}

Another case that is less important but @georgeocrawford would murder me for if we didn't allow when/if we make lintspaces part of our git pre-commit hooks.

Lining up variables with spaces (after indenting to the correct level with tabs):-

module.exports = function() {
  var a = '1',
      b = 2,
      c = false;

  alert("Hello");
};

Which outputs with this:-

{  
   "./test.js":{  
      "2":[  
         {  
            "line":2,
            "code":"INDENTATION_TABS",
            "type":"warning",
            "message":"Unexpected spaces found."
         }
      ],
      "3":[  
         {  
            "line":3,
            "code":"INDENTATION_TABS",
            "type":"warning",
            "message":"Unexpected spaces found."
         }
      ],
      "4":[  
         {  
            "line":4,
            "code":"INDENTATION_TABS",
            "type":"warning",
            "message":"Unexpected spaces found."
         }
      ]
   }
}

What do you think would be the best way to approach this?

IndentationGuess Rule #2 - indentation is less than previous line.

The rules of indentationGuess are as follows:

// The indentation of the current line is correct when:
// * the amount of indentations is equal to the previous or
// * the amount of indentations is less than the previous line or
// * the amount of indentations is one more than the previous line
// * the amount of indentations is zero and the lines length is also
// zero which is an empty line without trailing whitespaces

According to these rules, the following code PASSES:

var fake = function() {
  var n = 0, x = 0;
  for (n = 0; n < 10; n++) {
    for (x = 0; x < 10; x++) {
 console.log('improper indentation');
    }
  }
}

This passes rule 2, above. Rule 2 should read:

// * the amount of indentations is one less than the previous line or

Validation fails on Windows

Confusion between ignore `js-comments` and `newlineMaximum`

When i use

options: {
  ignore: [
    "js-comments"
  ],
  newlineMaximum: 1
}

the ignored comments are counted as new lines. And i get an newlineMaximum error.

Example code:

var app = app || {};

/**
 * Methods for handling the header
 */
app.Header = new Model({

  /**
   * Initialize the model
   */
  init: function() {}

});
…

When i use the settings like above an newlineMaximum error raises. If i remove the first comment, the second comment then becomes the error.

What can i do?

Byte order mark characters

Byte order mark character (BOM) at the beginning of a file causes lintspaces to report unexpected spaces. It would be good if this was a configurable option.

Add caching

According to the issue at lintspaces-cli (evanshortiss/lintspaces-cli#23) we could add support for caching.

[EditorConfig] "insert_final_newline = false" doesn't produce warnings in files that contain final newlines.

According to the EditorConfig website's supported properties section and editorconfig/editorconfig#269 (comment), insert_final_newline = false is supposed to ensure a file doesn't end with a final newline. The EditorConfig editor plugins I tried also work in that way - they strip out final newlines when saving files associated to .editorconfig files that have that property set to false.

However, lintspaces' equivalent newline property doesn't work in the same way. According to the newline option's documentation, it's solely designed to check for the the presence of final newlines and isn't capable of doing the opposite.

Since lintspaces' .editorconfig option works by remapping insert_final_newline to newline, that causes a clash between both interpretations.

Could something be done to make lintspaces' .editorconfig option follow that format's more aggressive interpretation of insert_final_newline = false?

Code/Output samples...
The samples below demonstrate how lintspaces currently reacts to insert_final_newline = false when a file contains a final newline.

.editorconfig

root = true

[*]
insert_final_newline = false

test.txt (contains a final newline)

test

check.js

var Validator = require('lintspaces');

var validator = new Validator({editorconfig: '.editorconfig'});
validator.validate('test.txt');

var results = validator.getInvalidFiles();

//Derived from https://stackoverflow.com/a/10729284
const util = require('util');

console.log(util.inspect(results, {showHidden: false, depth: null}));

Output when running node check.js in Windows:

{}

Expected output of node check.js:

{ 'test.txt':
   { '2':
      [ ValidationError {
          line: 2,
          code: 'NEWLINE_AMOUNT',
          type: 'warning',
          message: 'Unexpected additional newlines at the end of the file.' } ]
} }

Can lintspaces *fix* spaces?

From what I understand this tool reports only - is there anything that uses this report to fix things? Thanks for our attention!

bug with newlines

Maximum amount of newlines exceeded. Found 3 newlines, expected maximum is 2. in /some/path/to/file/unified-modal.php:3

<?php
namespace feature\unifiedModal;

/*
    <a href="#"
        class="btn btn-info ladda-button"
        data-ui-component="unified-modal-opener"
        data-style="zoom-in"
        data-title="..."
        data-size="md"
        data-header="true"
        data-footer="false"
        data-render="contact-form"
        data-view="Заголовок"
        >
        <span class="ladda-label">...</span>
    </a>
**/

/**
 * Unified modal action
 *
 * @throws \Exception
 */

Add CLI functionality

Hi,

I've wrapped a CLI around lintspaces in this repo. This could be added to the main node-linstapces repo in a /bin folder as a pull request if you like. The package.json could then be updated with a "bin" field.

Can't validate files on Windows with .editorconfig

Could find some issues regarding Windows but the all seem resolved. This library works perfectly on Unix, but on Windows the call to validator.getInvalidFiles() just returns an empty object. Any ideas?

indent tags, not attributes, for html files

When dealing with html files, it's often useful to align the attributes of a given tag together. As the tag name vary in length, this implies that the lines beginning with an attribute will not comply with the indentation setting. This is usually handled by editorconfig based plugins, but is treated as an error by gulp-lintspaces.

Integration rc and allows you to declare settings in .lintspacesrc

https://github.com/dominictarr/rc

Supporting editorconfig version 1.0.1

Hey! We're using node-lintspaces in one of our plugins at Code Climate to analyze code using editorconfig. We're looking to update the plugin with editorconfig 1.0.1. I noticed that the package is already updated in master to that version, but it's not yet released. Is there an ETA for a release supporting said version?

Thanks!

Behavior for `insert_final_newline = true` is inverted.

In an .editorconfig file when insert_final_newline = true, it means that files should end with a blank new line. The lintspaces implementation works in reverse. When I set insert_final_newline = true in my .editorconfig file, lintspaces complains about all of my files ending with newlines, but that's actually what I want, and I'd like to be able to get an error/warning if a file is missing that newline. From the EditorConfig docs;

insert_final_newline: set to true ensure file ends with a newline when saving and false to ensure it doesn't.

fs.statSync() fails when path doesn't exists

Find good solution to handle this behavior for the function _loadSettings bause else case isn't reachable.

setting dont allow bom

would be nice with a setting that would NOT allow BOM in the start of the file

I have a BOM file that just passed though

I ran:
`lintspaces --endOfLine 'lf' --newline --trailingspaces --indentation 'tabs' --verbose

testbom.txt
testbom.txt`

Latest version will not install on Mac OS X Mavericks

It looks like the pinned version of editorconfig being requested by node-lintspaces has some non Mac compatible pathing. The latest version of editor config does indeed install. Let me know if you need more information...

npm ERR! Darwin 13.4.0
npm ERR! argv "node" "/Users/a936040/.nvm/v0.10.38/bin/npm" "install" "lintspaces@latest"
npm ERR! node v0.10.38
npm ERR! npm v2.7.6
npm ERR! path /Users/a936040/Workspace/coreui/node/node-browse/node_modules/lintspaces/node_modules/editorconfig/bin\editorconfig
npm ERR! code ENOENT
npm ERR! errno 34

npm ERR! enoent ENOENT, chmod '/Users/a936040/Workspace/coreui/node/node-browse/node_modules/lintspaces/node_modules/editorconfig/bin\editorconfig'
npm ERR! enoent This is most likely not a problem with npm itself
npm ERR! enoent and is related to npm not being able to find a file.
npm ERR! enoent

npm ERR! Please include the following file with any support request:
npm ERR! /Users/a936040/Workspace/coreui/node/node-browse/npm-debug.log

Installation fails using latest npm

When using npm>2.7.5 the installation of lintspaces fails.

npm ERR! Linux 3.19.0-16-generic
npm ERR! argv "node" "/usr/bin/npm" "install" "--no-rollback"
npm ERR! node v0.12.2
npm ERR! npm  v2.9.0
npm ERR! path /home/remco/d-centralize/dc-app-cordova/node_modules/grunt-lintspaces/node_modules/lintspaces/node_modules/editorconfig/bin\editorconfig
npm ERR! code ENOENT
npm ERR! errno -2

npm ERR! enoent ENOENT, chmod '/home/remco/d-centralize/dc-app-cordova/node_modules/grunt-lintspaces/node_modules/lintspaces/node_modules/editorconfig/bin\editorconfig'
npm ERR! enoent This is most likely not a problem with npm itself
npm ERR! enoent and is related to npm not being able to find a file.
npm ERR! enoent

npm ERR! Please include the following file with any support request:
npm ERR!     /home/remco/d-centralize/dc-app-cordova/npm-debug.log

I think this is due to a bug in the version of editorconfig on which lintspaces depends and it can be solved by simply bumping the editorconfig dependency version to at least 0.12.2.

See editorconfig/editorconfig-core-js@68f81ca

[EditorConfig] Disable properties that use "unset" or invalid values.

Lintspaces' editorconfig option currently has inconsistent support for properties that have been set to be disabled. A few seem to work, but most don't. Not sure if the ones that already work are by design.

EditorConfig's documentation claims that the unset value can be used to disable any property (including ones that were set earlier). Before unset was officially decided upon in editorconfig/editorconfig#287, editorconfig/editorconfig#262 (comment) had recommended using any invalid value to achieve the same effect.

Would it be possible to fully support disabling properties?

Code/Output samples...
The samples below demonstrate how lintspaces currently reacts to disabled properties.

.editorconfig

root = true

[*]
indent_style = space
indent_size = 2
end_of_line = cf
insert_final_newline = true
trim_trailing_whitespace = true

[test.txt]
 #Working
indent_style = unset
indent_size = unset
#Not working
end_of_line = unset
insert_final_newline = unset
trim_trailing_whitespace = unset

test.txt

 spaces 
	tab

check.js

var Validator = require('lintspaces');

var validator = new Validator({editorconfig: '.editorconfig'});
validator.validate('test.txt');

var results = validator.getInvalidFiles();

//Derived from https://stackoverflow.com/a/10729284
const util = require('util');

console.log(util.inspect(results, {showHidden: false, depth: null}));

Output when running node check.js in Windows:

{ 'test.txt':
   { '1':
      [ ValidationError {
          line: 1,
          code: 'END_OF_LINE',
          type: 'warning',
          message: 'Incorrect end of line character(s) found.',
          payload: { expected: 'unset', end_of_line: 'CRLF' } },
        ValidationError {
          line: 1,
          code: 'TRAILINGSPACES',
          type: 'warning',
          message: 'Unexpected trailing spaces found.' } ],
     '2':
      [ ValidationError {
          line: 2,
          code: 'NEWLINE',
          type: 'warning',
          message: 'Expected a newline at the end of the file.' } ] } }

Expected output of node check.js:

{}

add documentation

respect file extensions definitions in .editorconfig

It seems that the plugin will not account for [*.extension] specific declarations in .editorconfig file when using the editorconfig option (was https://github.com/ck86/gulp-lintspaces/issues/10 )

[EditorConfig] Unrecognized values in charset property throw exceptions.

Lintspaces doesn't claim to support .editorconfig's charset property, but appears to be reading it and attempting to use it in a way that can lead to exceptions.

An exception can occur if the charset property's value is unrecognized. Out of EditorConfig's 5 supported charsets, lintspaces seems to understand latin1, utf-8 and utf-16le, but errors out with utf-16be and utf-8-bom.

The same is also true for unset/invalid values. Btw I didn't cover the charset property in #47 since its exception would've prevented other warnings from appearing.

Would it be possible to either completely ignore the charset property or improve lintspace's handling of it?

Code/Output samples...
The samples below demonstrate how lintspaces currently reacts to a charset = utf-8-bom property.

.editorconfig

root = true

[*]
charset = utf-8-bom

test.txt (BOM's presence doesn't matter)

test

check.js

var Validator = require('lintspaces');

var validator = new Validator({editorconfig: '.editorconfig'});
validator.validate('test.txt');

var results = validator.getInvalidFiles();

//Derived from https://stackoverflow.com/a/10729284
const util = require('util');

console.log(util.inspect(results, {showHidden: false, depth: null}));

Output when running node check.js in Windows:

internal/fs.js:21
    throw new Error(`Unknown encoding: ${encoding}`);
    ^

Error: Unknown encoding: utf-8-bom
    at assertEncoding (internal/fs.js:21:11)
    at getOptions (fs.js:80:5)
    at Object.fs.readFileSync (fs.js:549:13)
    at Validator._loadFile (C:\lintspaces-testing\node_modules\lintspaces\lib\Validator.js:123:18)
    at Validator.validate (C:\lintspaces-testing\node_modules\lintspaces\lib\Validator.js:66:8)
    at Object.<anonymous> (C:\lintspaces-testing\check.js:4:11)
    at Module._compile (module.js:652:30)
    at Object.Module._extensions..js (module.js:663:10)
    at Module.load (module.js:565:32)
    at tryModuleLoad (module.js:505:12)

Expected output of node check.js:

{}

JS Ignores failing when maximum newlines is set

May be the same issue as reported in schorfES/grunt-lintspaces#21

It seems to appear when the comments have no leading indentation.

/*
 * This is failing....
 * Foo
 * bar
 * baz
 */

while:

    /*
     * This is NOT failing....
     * Foo
     * bar
     * baz
     */

How to ignore some files and folder so those should not be linted?

Add error types/codes

For a better error type detection add a specific code or name to the report instead of a single custom error message.

Now:

{
    "/path/to/file.ext": {
        "3": [
            "Unexpected spaces found.",
            "Unexpected trailing spaces found."
        ],
        "12": [
            "Expected a newline at the end of the file."
        ]
    }
}

Better would be something like this:

{
    "/path/to/file.ext": {
        "3": [
            {
                type: "indentation",
                message: "Unexpected spaces found."
            }, {
                type: "trailingspaces",
                message: "Unexpected trailing spaces found."
            }
        ],
        "12": [
            {
                type: "newline",
                message: "Expected a newline at the end of the file."
            }
        ]
    }
}

UTF-8 charset

EditorConfig has an option for charset = utf-8 but it is not possible to validate this using this package. It would be a useful check. The only valid option for charset would be utf-8.

.editorconfig option from dependency not working, even though file exists

I've been having trouble with the editorconfig option (see AlbertoElias/gulp-lintspaces#4).

When I pass in editorconfig: '.editorconfig' the feature works as expected. However, if I try to pass in an .editorconfig file from one of my dependencies (editorconfig: './node_modules/@myorg/code-standards/.editorconfig'), I don't get any linting errors reported. I verified that the file exists when node-lintspaces looks for it (if I remove the file from the dependency, I get Error: The config file "./node_modules/@myorg/code-standards/.editorconfig" wasn't found.).

I also tried renaming my .editorconfig file to .nonstandardname and passing in editorconfig: '.nonstandardname', and everything works as expected.

Any ideas why the file at ./node_modules/@myorg/code-standards/.editorconfig wouldn't work?

better error output on lint errors

What is the benefit of this tool?

indentationGuess throws false positives on intermediate blank lines

As @denis-sokolov reports, indentationGuess throws false positives on intermediate blank lines.

foo(function(){
  if (foo) {
    // One is good for you
    doOne();

    // Two is not bad as well  <-- warning on this line
    doTwo();
  }
})

Test on multi os with travis ci

Add multi os support using the following guide https://docs.travis-ci.com/user/multi-os/

Single-line files are not caught by `newline` check.

On this line, the newline check is only run if the line number is greater than one. This means that files with a single line of content that lack a trailing newline are not reported as errors.

Check for newline character

I would love to see a check for newline characters that can be either set to e.g.

• IGNORE (all types allowed - default)
• CRLF (Window)
• LF (UNIX)
• CR (Classic Mac)

Especially if you have some developers working on Windows they sometimes commit CRLF line endings accidentally.