Discussion: How should linter requests be handled that should rather be provided by Google?

[carstenhag]

I have some linter requests that should probably be implemented by Google, because they don't fall in a "best-practice" but rather in a "issue" category, such as

• https://issuetracker.google.com/issues/246298892
• https://issuetracker.google.com/issues/207785210
• https://issuetracker.google.com/issues/199496149.

I currently wouldn't know how to contribute to their linter. Also, I am not sure when or if at al they will implement those linter rules. So because of that: Should this repo implement them then, or not?

[carstenhag]

And with https://issuetracker.google.com/issues/227070844 we are going full circle :D

[mrmans0n]

https://issuetracker.google.com/issues/199496149

For this one we are adopting internally kotlinx immutable collections which Compose understands. We are already using it for our paginated lists model, no issues. The plan we are following with that is to add linters for our MviViewModels to use PersistentList/Map/Set in them, and to add linters too for consumption of Lists in composables. This will likely end up being in this repo. Eventually the mutable check will flag Lists too, so we can denylist them easily (but I'd rather offer a custom message for that one, pointing to ImmutableList)

https://issuetracker.google.com/issues/207785210

Edit: tried this on Eel canary 10 and Compose 1.2.1 and it worked for a private class, so it's might not be a thing anymore?

https://issuetracker.google.com/issues/246298892

Oh wow this is a pretty imaginative one. But it would make sense to do as well. Might be harder than it looks looking at the code at face value (if there are different overrides with different types, as without class solving in ktlint I doubt we can do this safely easily).