StyLua icon indicating copy to clipboard operation
StyLua copied to clipboard

.styluaignore isn't respected when comparing a single file

Open stopdropandrew opened this issue 3 years ago • 5 comments

For instance,

If I have a .styluaignore file that looks like: path/

This will check the file: stylua -c path/to/file.lua

But this would not: stylua -c .

As an alternative, I can do stylua -g path/to/file.lua -- . But then I'm doing a full directory scan on each call.

stopdropandrew avatar Feb 17 '22 19:02 stopdropandrew

When you run stylua -c path/to/file.lua, is the .styluaignore in the cwd you are running from? I remember a similar issue a while ago that was resolved, https://github.com/JohnnyMorganz/StyLua/issues/249. I wonder whats different here

JohnnyMorganz avatar Feb 17 '22 19:02 JohnnyMorganz

In my actual case, it's midway up the path, but I just tried putting in a .styluaignore in the cwd and it seems to be ignored. It looks like the vscode extension works a little differently than CLI in this case.

stopdropandrew avatar Feb 17 '22 19:02 stopdropandrew

The VSCode extension looks for .styluaignore in the root of the currently open workspace (it has to implement its own ignore detection as it just passes in file content through stdin). It shouldn't be different from running the same command in the same workspace folder on the command-line though, so I'm not too sure what the difference could be there.

We could potentially search ancestor directories for a .styluaignore when running the CLI though. Maybe tagged behind the --search-parent-directories flag used for searching for config files? (https://github.com/JohnnyMorganz/StyLua#finding-the-configuration)

JohnnyMorganz avatar Feb 17 '22 19:02 JohnnyMorganz

Yeah either that or if you could combine them, like: stylua -c path/to/file.lua -- .

So it could use the path to build up to the file and look for ignore files in between. Even if it started from cwd and worked up would help.

stopdropandrew avatar Feb 17 '22 20:02 stopdropandrew

Spent some time examining this further, but it turns out this is a limitation in the dependency we are using to traverse and ignore files.

We actually are already specifying to look in parent directories for a .styluaignore file, and it does seem to be finding it, but for some reason when stylua -c path/to/file.lua is run, it is not marking the file as ignored.

It seems as though internally when its matching the gitignores, its using the file path given as the root of the gitignore, which is incorrect, an example of the issue can be seen in a directory structure like:

sub/
  ignored/
    foo.lua
  bar.lua
.styluaignore

with .styluaignore set to ignored/, and then running stylua sub/, it ignores the ignored/ directory and foo.lua, even though it shouldn't.

The dependency we used doesn't seem to really be maintained (the author wants to completely rewrite the crate some time in the future), so the only way around this I guess is to handle all this logic manually.

Refs: https://github.com/BurntSushi/ripgrep/issues/1909 https://github.com/BurntSushi/ripgrep/issues/1394 https://github.com/BurntSushi/ripgrep/issues/278 https://github.com/BurntSushi/ripgrep/issues/829

JohnnyMorganz avatar Mar 07 '22 20:03 JohnnyMorganz

When this issue was initially created, I think I misunderstood the behaviour initially, and the fact that the file was midway up the path was a red herring.

This should soon be possible via #765 and the --respect-ignores flag.

I am going to close this as a duplicate of #751

JohnnyMorganz avatar Sep 16 '23 20:09 JohnnyMorganz