Different output when running credo with the --read-from-stdin option

[GiovanniHessel94]

Hey I'm having an issue and I couldn't find anything related to it. Sorry if it has already being addressed somewhere else.

Environment

• Credo version (mix credo -v):

1.7.1-ref.main.eb7b5a4800+uncommittedchanges

• Erlang/Elixir version (elixir -v):

Erlang/OTP 24 [erts-12.3.2] [source] [64-bit] [smp:16:16] [ds:16:16:10] [async-threads:1] [jit]

Elixir 1.14.5 (compiled with Erlang/OTP 24)

• Operating system:

Versão do Windows: 10.0.22621.2428
Versão do WSL: 1.2.5.0

Expected outcome

I expected to have the same output when running the commands mix credo filename.ex --strict and mix credo --read-from-stdin < filename.ex --strict in the same file.

Actual outcome

It seems that with the --read-from-stdin option it detects the readability:Credo.Check.Readability.ModuleDoc while without the option it doesn't.

[rrrene]

Thx for reporting this 👍

Unfortunately, I can not reproduce this on my machine. One thing I noticed is that the --strict is misplaced:

mix credo --read-from-stdin < filename.ex --strict

should probably be

mix credo --strict --read-from-stdin < filename.ex

Could you check that?

[GiovanniHessel94]

@rrrene sorry for the late response, tried that and the output is the same (as It should probably be).

I think "the problem" is in this line, it only happens in the test files, as per the example, and those are .exs so it returns an empty list when running the mix credo command, now when we use the --read-from-stdin the filename comes as stdin so the rules are applied.

Not sure if anything should be done about it, but that seems to be the reason of the different output using this option, and as I'm using the vsCode extension and it seems to* use it, this warning is always present in the test files.

[rrrene]

@GiovanniHessel94 ah, you are right. 👍

The filename can be passed and it seems that the integration you are using is not making use of that feature.

[GiovanniHessel94]

I'll open an issue in their repo, so I think we can close this one. Thanks!