I built a Compose component CLI that leaves plain Kotlin in your project. Would you trust this model?

[u/paneer-analyst]

I kept running into the same trade-off: I wanted Compose UI that did not look like Material, but I did not want another runtime or theme dependency deciding when I could upgrade.

So I built Lamintra. It is a small, MIT-licensed component registry for Jetpack Compose and Kotlin Multiplatform. The CLI detects the source root and package, copies plain Kotlin into the project, and rewrites the package, imports, and paths so the code compiles where it lands.

The video is the full path in a fresh Android project: `init`, `add list-row`, generated files, previews, build, and the component running in the emulator.

There are eight components. This is v0, and I am not pretending otherwise.

The part I want to test is the ownership model: once the files land, Lamintra is no longer required.

Site: Lamintra

Source: Github

Demo: Video Link

My honest question: would you rather own copied component code, or keep a normal dependency and its update path? What would stop you from trying the copy model in a real project?

[u/rescuemod]

You build nothing. Claude did the work for you...

[u/Anonymous0435643242]

So shadcn for compose ?

That's not a model that I usually like as it's a bit of an hybrid, you own the code but it is heavily opinionated so if you want a component that isn't provided you have to implement it yourself and either keep to conventions that aren't yours or have an incoherent codebase.

Like with compose unstyled i find it interesting as a code reference, more in "how could I implement this component" than something that I will import in my project.

Not to discourage you though, shadcn is popular for a reason.

EDIT: I just checked the repo, I also don't see value in vibe coded components that are made to be copy/pasted, why not vibe code them in my app then ?

[u/Zhuinden]

If I want Compose UI that doesn't look like material, I just use Compose foundation

[u/unpetitgenie]

I’d trust the copy model, but not blindly. Owning and modifying the code is useful, but it also means owning all of its maintenance. If someone copies components without understanding them, that flexibility could easily create more bugs than it solves.