Will the "internals" of material3 components ever ...

# compose

[eygraber]

Will the "internals" of material3 components ever be made not internal? For example, all of the tokens, things like ButtonColors, etc... Would be helpful to have access to them in some scenarios, especially since they are read only anyways.

[francisco]

We have a custom Design System Theme and cannot use/extend material colors so having acccess to ButtonColors ChipColors etc would be so helpful.
My current solution is to basically copy the ChipColors internal functions in my DS Library, but would be helpful if they exposed them.

[eygraber]

Yup, that's what we've been doing as well, but obviously very brittle if anything ever gets changed (not that it should change because it follows the material3 spec, but you never know...)

[ephemient]

@file:Suppress("INVISIBLE_MEMBER", "INVISIBLE_REFERENCE")

or hacks with friend paths can let you access `internal`s of other modules (usual caveats about "if it breaks, you get to keep the pieces"), but yes this seems like something that would be useful as a public API

[Yann Badoual]

FYI an issue about this exact problem: https://issuetracker.google.com/issues/247717552


I'm personally working on a script to pull each compose release, switch everything internal to public, and re-publish as a maven artifact because of this exact issue (and some other useful API that is hidden).

[ephemient]

that would be possible with an artifact transform in Gradle, if your feel motivated to do so

[ephemient]

but given that there's non-invasive ways to bypass internal I don't see why you would

[james]

I’m curious about this @ephemient, what are the non-invasive methods of bypassing Kotlin’s internal modifier? it used to be easy in the world of Java, but I’ve not seen a way of doing it in Kotlin

[ephemient]

@Suppress, as I mentioned just earlier

[james]

AH 🤦 I’m sorry, somehow I read this thread and missed your first comment — apologies!