schorfes / node-lintspaces Goto Github PK
View Code? Open in Web Editor NEWA validator for checking different kinds of whitespaces in your files.
Home Page: https://npmjs.com/package/lintspaces
License: MIT License
A validator for checking different kinds of whitespaces in your files.
Home Page: https://npmjs.com/package/lintspaces
License: MIT License
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?
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
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 character (BOM) at the beginning of a file causes lintspaces to report unexpected spaces. It would be good if this was a configurable option.
According to the issue at lintspaces-cli (evanshortiss/lintspaces-cli#23) we could add support for caching.
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.' } ]
} }
From what I understand this tool reports only - is there anything that uses this report to fix things? Thanks for our attention!
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
*/
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.
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?
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.
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!
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 totrue
ensure file ends with a newline when saving andfalse
to ensure it doesn't.
Find good solution to handle this behavior for the function _loadSettings
bause else
case isn't reachable.
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`
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
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
.
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
:
{}
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 )
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
:
{}
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
*/
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."
}
]
}
}
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
.
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?
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();
}
})
Add multi os support using the following guide https://docs.travis-ci.com/user/multi-os/
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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.