How do folks deal with breaking out a library into multiple kotlinlang #library-development

How do folks deal with breaking out a library into multiple modules, while continuing to hide APIs that shouldn’t be public but need to be shared internally across modules?

louiscad

10/21/2020, 9:34 PM

I use

@InternalLlibsXApi

with

public

declarations. I've also been considering making an internal labelled artifact used with

implementation

scope.

For the solution relying on

@RequiresOptIn

annotated annotation, I avoid the top-level scope or common types extensions (e.g.

String

) to not have the users see them in autocomplete. Now, I'm thinking a

HIDDEN

level would be nice for

@RequiresOptIn

, where you need to know it exists in the first place to enable it and then see it. Something for #language-proposals and :youtrack: I guess.

travis

10/21/2020, 9:46 PM

friend-paths

compiler option would probably be a good option, but I could never get it working. :(

russhwolf

10/21/2020, 11:06 PM

The supported way to do this is with a

@RequiresOptIn

annotation. JetBrains does this in a couple places in their libs which I think is a big part of why they renamed it from

@Experimental

. I keep getting a weird impulse to find hacky ways to prevent consumers from opting into such annotations when it's truly meant for internal use only (reduce the visibility! make it private!) but haven't found anything that doesn't just create a bigger mess.

basher

10/22/2020, 2:17 AM

thanks all!

huh didn’t know about friend-paths: https://youtrack.jetbrains.com/issue/KT-20760

travis

10/22/2020, 5:23 AM

Would love to see

friend-paths

be configurable via Gradle, as none of the tinkering I did seemed to make it work. Similar to you, I was hoping to have an internal module, and that compiler directive seems like a good fit. 🤷

#library-development Join Slack