Could error return codes not be used for ignored or unparseable files?

[raddessi]

Subject of the feature

Could error return codes not be used for ignored or unparseable files?

Problem

I'm trying to use this with pre-commit but unfortunately if pre-commit calls alex <some file that is unparseable or ignored via config> then alex returns a failure exit code rather than just a message. This causes precommit to think there is an actual problem when there is not.

Expected behaviour

Ideally an error code would only be used it a positive match was found.. or maybe this could be a config flag?

Alternatives

Alternatively I can possibly hack around this by putting the call to alex in a bash loop.. but I think this is not an ideal option.

Thanks for your work on this!

[wooorm]

I don’t understand what you mean by unparsable. The input alex understands are text, html, and markdown: all languages that do not know errors. All input you throw at them is parsable.

For ignored files, I believe pre-comment has options for this?

[raddessi]

Ok I apologize, ignore the comment about unparseable content then. It isn't really directly needed for this so I shouldn't have brought it up - the main issue I'm seeing is just the ignored file error handling.

For ignored files, precommit does have methods for forcing that but the standard pattern to follow is to set those rules in the config for the linter directly so that you can run the tool on its own for quick checks if desired, or in case a dev using the repo does not actually use precommit and runs the linter directly as their normal procedure. This is why I ask, since I put my config in the alex config files like I would normally do with other linters and let precommit run the linter with its own configuration.

[wooorm]

I’m sorry, I don’t know enough about pre-commit to advise you on how to use it. But they seem to have a bunch of advanced options that might help: https://pre-commit.com/#advanced

[raddessi]

Oh no worries about pre-commit, I know it very well already :) I was actually really hoping you would be open to changing the return code raised from alex when it is ran against a file that is ignored via alex's config. The way other linters behave (at least from what I have seen) is that they exit gracefully and do not count that as an error if other files are being tested at the same time as the ignored file. This would make it much easier to integrate with other tools like precommit while still allowing config for alex to be set in it's own config files. Each of the ignored files would be handled by emitting a message that the file is ignored similar to how it currently is being emitted but the ignored file would not count as an error so that if no other real violations were encountered then the script would exit with a return code of 0.

If you're not open to it that's ok.. just disappointing as it will make configuration much more complex and could require duplicated config

[wooorm]

I was actually really hoping you would be open to changing the return code raised from alex when it is ran against a file that is ignored via alex's config.

Typically, folks doing alex example.md, where example.md is in .alexignore, would be user error, and it shouldn‘t be silently ignored.

While it might require some configuration for pre-commit or using alex -- (assuming pre-commit passes the files, they would go after the two dashes, which should ignore them and run alex on everything instead). I believe the default should stay. I believe the CLI should be as minimal as possible.