.packsquashignore

[S42yt]

Related problem or need

Shader files completly brake by the packsquash

Proposed solution

A .packsquashignore like .gitignore

Alternative solutions

Just ignore shader files

Additional context

No response

[AlexTMjugador]

Hello, have you tried using the latest PackSquash unstable builds, as described here? They contain many fixes, including fixes affecting how shaders are processed, that are very likely to render such a feature not necessary.

[S42yt]

Hello, have you tried using the latest PackSquash unstable builds, as described here? They contain many fixes, including fixes affecting how shaders are processed, that are very likely to render such a feature not necessary.

but wouldnt be such a feature just handy in general?

[AlexTMjugador]

but wouldnt be such a feature just handy in general?

I appreciate your idea, but from my perspective it doesn't seem that "handy in general". There are some valid (though rather niche) cases where preserving a file exactly as it is in a resource or data pack is the only practical option (I've only heard of one so far, but there could be a handful more). For those situations, further work on this concept would be warranted. However, in most cases where people request such an ignore feature, what they really want is a way to work around an issue in how PackSquash processes certain files, as it was in your case. For the latter situation, I believe the better solution is to prevent PackSquash from breaking those files in the first place: it isn't particularly complex to do from a technical standpoint (in fact, it has already been done for shader files in unstable builds, though with some trade-offs in optimization potential), and it leads to a better user experience, as things would "just work" without any extra setup.

Setting aside how such a feature fits within PackSquash's scope, I'm also not convinced about introducing a separate .packsquashignore format for it. PackSquash already supports a flexible TOML-based configuration format, so adding another format to convey settings that can already be handled in TOML files feels disconnected from how the rest of the program works. In my view, in Git it makes sense to have both a configuration file and .gitignore, since configuration may be specific to users and shared across repositories, unlike .gitignores. But in PackSquash, there's no concept of configuration layering or, as far as I can tell, any need to split different settings across multiple files (and the hypothetical, ad-hoc needs I can imagine involving that would be better served by having similarly ad-hoc scripts to merge TOML snippets together into a TOML file suitable for PackSquash usage). So, if a feature like this gets added, I think it'd a better fit if it's configurable through the existing TOML configuration format.

[S42yt]

completly agree!