Please support files that just have extensions

[mikeblakeuk]

Please support files that just have extensions

> eclint fix **/*
events.js:160
      throw er; // Unhandled 'error' event
      ^

Error: EPERM: operation not permitted, open 'MyApplication\.vs\MyApplication\v14\.suo'
    at Error (native)

[gucong3000]

Already supported. It seems to have been caused by other mistakes operation not permitted, open 'MyApplication\.vs\MyApplication\v14\.suo'

try sudo

[mikeblakeuk]

I managed fix it by not using a filter e.g. just eclint fix I noticed that exe get changed

[gucong3000]

@mikeblakeuk I don't quite know how to reproduce what you're talking about.

[mikeblakeuk]

Two minor defects;

1. If you have a path filter and a file exists without a name (e.g. ".suo")
2. I would expect EXE (and PFX, CER or any binary) files to remain untouched Working now

[gucong3000]

If you have a path filter and a file exists without a name (e.g. ".suo")

Work fine for me. Some process may have locked this file.

[gucong3000]

I would expect EXE (and PFX, CER or any binary) files to remain untouched Working now

I am woking on this. #65

[gucong3000]

releases v2.1.0 already created: https://github.com/jedmao/eclint/releases/tag/v2.1.0

@jedmao Could you please publish it to npm?

[mikeblakeuk]

To be fair, our .editorconfig has [*] and we might change this.

[gucong3000]

To be fair, our .editorconfig has [*] and we might change this.

@mikeblakeuk I was confused. Please describe the problems you have encountered, and how can I reproduce your problems?

[jednano]

You might also do well to put all your source files in a src folder so you don't have any exe files in there.

[mikeblakeuk]

@gucong3000 I think that our .editorconfig might be wrong. Instead of skipping binary files, we shouldn't use [] in our .editorconfig. We should change our config to [.cs]. I think the fix you have (#65) is a good one tho because it will improve performance skipping exes and i would expect that you don't want "editor" settings changing dll files

@jedmao I run eclint before I commit. On a C# project there could be a "packages" folder with dlls from NuGet that i don't want fixing (breaking). I guess i could write a hook / filter.

My use case is

PS:> git clone MyRep
PS:> npm install -g eclint
PS:> eclint fix
PS:> git add . //or commit

[gucong3000]

@mikeblakeuk Please try the latest version. Most of the common binary file formats will be ignored

[gucong3000]

In our company project, we also use eclint in githook

var reporter = require('gulp-reporter');
var eclint = require('eclint');
var eslint = require('gulp-eslint');
var fileType = require('file-type');
var filter = require('gulp-filter');
var git = require('gulp-git');
var gulpif = require('gulp-if');
var postcss = require('gulp-postcss');
var stylelint = require('stylelint');
var postcssSyntax = require('postcss-html');

function excludeBinaryFile(file) {
    return !(file && file.isBuffer() && fileType(file.contents));
}

function excludeMinFile(file) {
    return !/\Wmin\.\w+$/.test(file.path);
}

function isEsFile(file) {
    return /\.(?:js|jsx|es\d*|vue)$/i.test(file.extname);
}

function isStyleFile(file) {
    return /\.(?:s?css|sass|less|sss|vue|php|html?)$/i.test(file.extname);
}

git.diff('origin/master...')
    .pipe(filter(excludeBinaryFile))
    .pipe(filter(excludeMinFile))
    .pipe(eclint.check())
    .pipe(gulpif(isEsFile, eslint()))
    .pipe(gulpif(isStyleFile, postcss([stylelint], {
        syntax: postcssSyntax
    })))
    .pipe(reporter());

It will only lint files that differences with origin/master branch.

This will follow the configuration in .gitignore file.

[morewry]

I am also seeing a behavior that led me to believe that eclint might not support files with just extensions. It's an unexpected behavior because it is inconsistent with how my IDE's editorconfig plugin behaves on the same files, but I'm not sure what the root cause is. However, from my perspective, it appears that eclint is ignoring dotfiles for both eclint check and eclint fix.

My .editorconfig reads,

root = true

[*]
charset = utf-8
end_of_line = lf
indent_size = 2
indent_style = space
insert_final_newline = true
trim_trailing_whitespace = true

I can give more info on what I'm doing and why if you'd like, but for now I'll leave the narrative out, because it can be reproduced very easily:

> echo -n '{"extends": "something"}' > .examplerc && wc -m .examplerc && ./node_modules/.bin/eclint fix .examplerc && wc -m .examplerc
      24 .examplerc
      24 .examplerc

This creates an extension-only/dot file (similar to .eslintrc, one of the real files on which I'm seeing this behavior) without a final newline. I then count the bytes in the file, which is 24. Next I run eclint fix on the file and count the bytes again--still 24. eclint didn't insert a final newline.

In comparison, if I open up the file in Atom and save it (without making any other changes), the editorconfig plugin inserts a final newline. In the editor, of course, it's visually obvious, but running another count on the file afterward confirms the change.

> wc -m .examplerc
      25 .examplerc

Compare this to the same process on a markdown file:

> echo -n '# Heading 1' > example.md && wc -m example.md && ./node_modules/.bin/eclint fix example.md && wc -m example.md
      11 example.md
      12 example.md

As you can see, the behavior is very different on the file that has a file name and extension, even though nothing else is different in how the two files are created or worked with. And, yes, simply adding a single character before the extension changes the result:

> echo -n '{"extends": "something"}' > a.examplerc && wc -m a.examplerc && ./node_modules/.bin/eclint fix a.examplerc && wc -m a.examplerc
      24 a.examplerc
      25 a.examplerc

That's what I personally expected to have happen in the first example, rather than the file being skipped. I'm assuming from the behavior of the editorconfig plugin in Atom and this thread that it might be objectively unexpected.