Discussion: How should linter requests be handled that should rather be provided by Google? about compose-rules

[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).

[carstenhag]

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