Hello, library author noob here. I'm prepping to ...

# library-development

[Colton Idle]

Hello, library author noob here.

I'm prepping to release my first library (an android library to be exact) and since it's my first time, I'm looking for any advice in the form of a pre-release checklist. Similar to how android has a checklist for apps https://developer.android.com/studio/publish/preparing I was wondering if anyone has a checklist handy for publishing a library.

Here's the list that I've put together so far:
1. Create dokka docs and ship with the library
2. Go over your public API in your classes
3. Go over your dependencies to make sure you don't pollute consumers classpath
4. Proguard? (is that a thing for lib development)
5. Anything else?

[mbonnin]

LICENSE and CONTRIBUTING.md

[mbonnin]

Proguard is a thing if your lib requires reflection. You can ship your proguard rules alongside your lib by putting it in the appropriate folder (somewhere in META-INF IIRC)

[CLOVIS]

Add the Maven coordinates for the library in the Dokka module pages!

e.g. https://vite-kotlin.opensavvy.dev/api-docs/vite-kotlin/index.html

[Colton Idle]

Proguard is a thing if your lib requires reflection.

Can someone expand on that? Not sure I understand

[mbonnin]

You mostly don't want to proguard your lib unless you're a weird payment SDK that want to (try to) obsfuscate your lib

[mbonnin]

Proguard belongs in 99.9% of the cases to the final binary (also because more optimizations can be done there)

[mbonnin]

That being said, if your lib requires special proguard care, you can embed your specific rules in your lib so that people don't have to write them themselves

[Colton Idle]

Yep. Pretty much in that finance line. not that obfuscation is a bulletproof solution. but we (the company) decided not to go open source/publish sources. so that definitely a consideration.

[mbonnin]

I see

[Colton Idle]

Do people use KGP abiValidation on every release of their library to make sure they're not adding or changing the binary? is that something i should put in my list?

[mbonnin]

On every commit 🙂

[CLOVIS]

I don't, but yeah you should

[mbonnin]

The new KGP integration removed the check dependency but that was a mistake IMO: https://youtrack.jetbrains.com/issue/KT-78525/KGP-abiValidation-check-does-not-depend-on-checkLegacyAbi-when-enabled

[mbonnin]

You typically want to catch any breaking change as soon as possible

[Dan Rusu]

In addition to what everyone else said:
1. Go to the GitHub Insights -> "Community Standards" of your project, and try to have everything checked.
2. Setup GitHub CI to automatically build & run tests.
3. Spend lots of time improving your README as this is the most important aspect of open-source projects.
4. Publish in Maven Central and also use GitHub releases.
In case it helps. Feel free to snoop around my library for inspiration.

[Colton Idle]

@mbonnin you said you do that on every commit. is that something where you commit the newly generated file or what?

[mbonnin]

Yes, every change gets reviewed and commited

[Colton Idle]

interesting. i guess maybe i dont understand how those files are generated. i thought the gradle task always generates a file with the same name, but maybe it versions them or something. i haven't gotten it to work reliably so maybe thats the issue. in my head. you would run it on every commit with like a pre-commit hook, and it generates the file name based on the commit hash or something?

[CLOVIS]

I think it's a mistake too

[CLOVIS]

@Colton Idle it always overwrites the previous version, but since you committed the previous version, you can use git to see what changed

[mbonnin]

One example: https://github.com/apollographql/apollo-kotlin/pull/6735/files#diff-4e04037ee6683a4fcc588b8c1b91f6c5b3b14f7ef25a6efab2115fbd7bd5e588R288

[mbonnin]

Allows you to discuss the binary changes directly in the PR

[Colton Idle]

Thanks, that link is helpful.

Anyone have thoughts on buildConfig in an android lib? I can see in my library api dump that I'm bunding buildConfig

[mbonnin]

What do you need it for?

[Colton Idle]

basically right now its a few api keys that we bake into the library so that during compile time we can swap out those api keys for prod vs staging vs etc.

so they're completely internal to the library, but i did notice we expose them.

[mbonnin]

Should probably not be part of the public API indeed

[mbonnin]

Note that using flavors in KMP libraries is being kind of phased out (see also https://kotlinlang.slack.com/archives/C19FD9681/p1760349540399929)

[Paulo Cereda]

Enable explicit API mode? 😊

[CLOVIS]

This thread is making it very clear that we do need some kind of checklist lol

[CLOVIS]

Probably as a new page here

[Colton Idle]

fwiw its not a kmp lib. i will look into "explicit api mode". ive got my night free at the moment so ill be looking into how i can disable/prevent BuildConfig from being part of the public api.

[Colton Idle]

maybe dumb question. but whats the alternative to using build config for keys. as a lifelong android app dev thats kinda the first thing i reach for. AI keeps pointing me to wrapping buildConfig in my own class, but it seems like it will still technically be part of public api.

[CLOVIS]

I would never include the key in the library itself. Anyone who downloads the library can find the key and use it however they want. You probably want users of the library to supply their own key?

[mbonnin]

Yea, agree with Ivan. If you put a key in your lib, might as well commit it in source control

[mbonnin]

If you really want to keep this setup, you can look into https://github.com/gmazzo/gradle-buildconfig-plugin that generates internal BuildConfig by default but if your key is secret, it's only going to give you the illusion of security

[Colton Idle]

its not a secret. i just dont want to expose it as part of public api. so yes, we do actually have it committed to source control, i just dont want it to pollute my consumers

[mbonnin]

I don't know if Android supports generating BuildConfig as internal but you can take a look at gmazzo . Or maybe not even use BuildConfig at all? Just commit your key in source control as an internal val

[Colton Idle]

yeah, i guess we swap out some of the keys at compile time, and we do that in gradle. i will take a look at gmazzo. just wanted to make sure there wasn't some simple flag to make buildConfig private that I was missing.

I guess most libs just don't use BuildConfig

[Colton Idle]

oooh. used dokka for the first time. looks like my android compose `@preview`s are also part of my public api!
nice catch dokka!

[CLOVIS]

The ABI export would have told you too 🙂

[Colton Idle]

maybe i just didn't get that far down the abiExport lol. the dokka html is much easier to grok lol. im also unfortunately going on too little hours of sleep lol. just trying to wrap this project up!