.eslintignore File Location and related Search Pattern
See original GitHub issueTL;DR: Is there a special reason, why the .eslintignore file is not searched relative to the files which are linted?
Two weeks ago, I started using eslint with syntactic within vim. For the first few days, everything worked great, but then I came across that lib which had a totally different style than my code. So I thought I could simply create a .eslintignore
file. So I did and placed it in the same directory as my .eslintrc
. But it wasn’t found. So I placed it next to the file I wanted to edit, but it wasn’t found either. So I took a look at the documentation and found that eslint was searching in the current work directory.
I found this pretty weird because normally my editor does not care from which directory I edit a file. So I went to your gitter and had a short conversation with @platinumazure. I went on and wrote a little patch which fixes the issue (for me) and should break as little as possible.
The patch (https://paste.pound-python.org/show/w5HghbQWb0HjHfMxPyJc/) solves the problem by first looking in the CWD as before and extends its search for a .eslintignore
file starting with the directory of the first target js-file (argument from cli), upwards in the directory tree. If it cannot find an .eslintignore
file it continues relative to the next target file. The search terminates as soon as a .eslintignore
file is found or all parent directories have been searched. As directory trees are normally not that deep (who uses more than 20 directories in a path?), I think the overhead should be okay. I do not know with how many files as arguments people use eslint but when they would use many files directly as cli arguments (200?) in a deeply nested directory on a hard drive with cold FS-cache, it could take a few seconds to probe all those directories, but I think this is more of an edge case.
So what does the patch break: As the patch still searches the CWD first, the breakage should be minimal. The only case I am aware of is when someone uses a CWD without .eslintignore
but has some .eslintignore
file in a parent directory with matching paths and does not want to ignore those files. Very unlikely, but possible.
When I presented the patch to @platinumazure he advised me to either add tests and create a PR or create an issue first (to spare my resources), to ask, if there is a special reason, why this functionality was not built into eslint before. Since I did not have the time to create tests in the last two weeks I decided to start with the issue.
So what do you think?
- ESLint Version: v3.15.0
- Node Version: v7.5.0
- npm Version: 4.1.2
Issue Analytics
- State:
- Created 7 years ago
- Reactions:1
- Comments:9 (5 by maintainers)
Top GitHub Comments
@IanVS I am well aware of the #7678 dependency here.
So the problem I see here is that on the one hand eslint seem to depend heavily on the project root while at the same time there is no clear definition where to find it. Some say it is the directory with the
.eslintignore
file, others say it is the directory with the.eslinrc
containing"root": true
. I do not really care which one is the truth/better.The only thing I do NOT believe to be meaningful is to assume that the CWD is the project’s root.
Just to give an example. In some of my projects I have multiple “sub-projects” in close proximity:
Most of the time you are just in one of those sub-projects but sometimes you want to open multiple files from different sub-projects at the same time or you just want to edit a file from another sub-project for a short time.
Always closing the editor and starting it from another subdirectory sucks, but even when you run eslint from the command line (e.g. with --fix) it is really annoying if you always have to change to the correct directory first.
On the other hand, if we would try to find the project’s root based on the file path which eslint has to lint, it would make much more sense and if I am not mistaken eslint does so already when it searches for the
.eslintrc
.So an alternative to the initial patch could be, to agree on a definition of the project root which is based either on
.eslinrc
XOR.eslintignore
(ignoring the CWD), let eslint find the project root at the beginning and change into the project`s root directory before it starts the lint-process?@nzakas actually, it seems there was enough interest as someone implemented it. Current documentation states:
After the negative feedback here I just went on and forgot about the issue. Some day I noticed that ESLint behaves better now, but didn’t remember this issue was still open. So thanks for closing it and thanks to the person who fixed the behavior 👍