Help GitHub auto-hide .snap files in a PR

[nyurik]

Snapshot files tend to be very noisy, and GitHub has a feature that automatically collapses changes to such files, similar to how Cargo.lock is hidden by default. I started a conversation about it, and one issue is that .snap is used by more than one tool. Someone just made a good suggestion on how it can be improved https://github.com/github-linguist/linguist/pull/7235#issuecomment-2700436397 -- could someone help work on this to define identifying features of the .snap files? Thx!

[max-sixty]

I agree sometimes these are noisy, but sometimes they're also a really important diff — I think it depends on whether the assertions are "this output hasn't changed" vs "I want to manually inspect the output before approving any change"

I'd be up for moving this ahead if there were some file size limit — e.g. hide diffs if the files has >100 lines. Do you know whether that's an option?

[nyurik]

that's a good point - a smaller diff might be ok, but the larger ones should probably be hidden. GitHub does have that for the overall size of the change, but I don't know if this is part of the linguist, or some other system. I am not that great with Ruby :)

[spenserblack]

identifying features of the .snap files?

To answer this question: I believe that the YAML front matter in Insta snapshots could be suitable for Linguist. I haven't seen similar content in other snapshot libraries.

---
source: PATH/TO/FILE
expression: RUST_CODE_SNIPPET
---

Linguist is capable of reading some of the file when identifying its attributes, like whether or not it's generated.

---

But I want to point out that the definition of what is and isn't generated isn't strictly enforced in Linguist. For example, yarn.lock, which is almost always generated, was explicitly changed to not be considered generated (https://github.com/github-linguist/linguist/issues/4348). I wouldn't be surprised if Cargo.lock loses its "generated" status under the same reasoning.

So what I'm getting at is that, even though one might think that the obvious choice is to mark generated files as generated, it becomes a gray area when those generated files are meant for human review.

[nyurik]

heh, by that reasoning any file committed to git should be reviewed (and that's why I usually don't like generated files to be commited to git in the first place). The hiding concept is mostly for "focus" - i.e. highlight more important changes, and hide less important changes (but still keep them available to be expanded and reviewed)