Ignore warning always seems to print

[max-sixty]

What happened?

I had a quick go at fixing this but didn't make progress so here's a placeholder issue:

Currently it seems we always get this warning, even when no tests are ignored:

warning: some paths are ignored, use --no-ignore if you have snapshots in ignored paths.

This happens on a simple cargo insta test on both insta and prql

Reproduction steps

cargo insta test

Insta Version

1.23

rustc Version

1.66

What did you expect?

Only warn if we're actually ignoring something

[mitsuhiko]

That's a limitation I'm not sure I can easily remove. Unfortunately the underlying ignore crate does not report if it actually ends up using the ignored paths.

[max-sixty]

OK yes, makes sense.

FWIW — without much context beyond my own — I would quite prefer to have no warning.

Currently in PRQL, running the standard test suite raises warnings suggesting it should be run with --no-ignore, when actually that would have no effect. And I'm not sure how often people are using snapshots in ignored paths (some! #314).

Something to print a warning when writing a snapshot into an ignored path would solve this nicely, but be some work. And #282 would let us silence the warning.

Thanks again. People really like insta in PRQL, it's invaluable.

[mitsuhiko]

FWIW I'm with you and I also hate the warning and would like to get rid of it. so I'm not opposed at all to find ways to remove it. One potential option would be to just have the thing walk a second time afterwards without ignores and see if it picks up extra tests.

[max-sixty]

Without ignoring, it is much slower — at least on prql, 3.69s vs. 4.15s with --no-ignore for cargo insta test, including the fixed costs of running the tests.

Do you think it would be sufficient to raise an error if the root snapshot path were ignored? I could possibly add that here: https://github.com/mitsuhiko/insta/blob/master/cargo-insta/src/cargo.rs#L255

It doesn't cover the case where a sub-dir is ignored, or someone has ignored .snap, but could be quite rare. (@lu-zero if you have thoughts...)

[lu-zero]

I fixed the problem on my side, so I'm less impacted.
The simplest thing is probably add a configuration knob to silence the message.

[max-sixty]

I'll close this, since it's much less prevalent after #320, but please feel free to reopen if you want to track broader solutions