One thing I wonder about Amper, does it support co...

# amper

[Joel Denke]

One thing I wonder about Amper, does it support consume gradle convention plugins so can share Amper configs across modules and not duplicating same Yaml thing over and over again? In this case basic sample of one shared module. But for larger apps, or well most Android apps want to go KMP/CMP and/or with Amper, how to deal with this if having like 200 feature modules?
Like maybe worth keeping some convention plugins, and apply instead of using Amper, or with Gradle interop they using? Like can I have a shared Amper module I can share as base into another module I wonder about.

Also I wonder, does it offer autocomplete on more things than the new TOML files? Like platforms, autocompletes iOS? Or is everything manual in Yaml so to say? Feels like each IDE enforced to implement same autocomplete mechanism then. Meaning like Android Studio will get it kind of never, as using so old IntelliJ versions. I dont mind Fleet, but its not mature enough for everything I need, using it spareful.

[joffrey]

If you need to share configuration between YAML files, Amper offers the template feature, where you declare a file called <somename>.module-template.yaml anywhere you want, and then use apply: ./relative/path/to/template in the module file at the top level to use it. That's the equivalent of gradle's convention plugins. If you need to share custom Gradle config that cannot be expressed in Amper, you will have to use Gradle interop and Gradle convention plugins.

[joffrey]

Regarding auto-completion, toolability is one of the major goals of Amper, so it's important to us that users get proper completion, it's definitely not normal to edit plain yaml "manually". Make sure you have the Amper plugin installed and you're using the .yaml extension (not .yml) for module files if you don't get auto-completion.

[Joel Denke]

Oh nice, wasnt aware can use template like that, that sounds exactly like what I want 🙂 Is Amper intented to be the new thing scaling up for Kotlin multiplatform and all IDEs?
Or does that depend what the community input about Amper?
Would like to not try using Amper and then suddenly Jetbrains is deprecate it and abandon it. Havent read about commitment from Jetbrains, if intend make it work good everywhere, with IntelliJ plugins or only go for Fleet.
Feels like a two edges sword, need to use Fleet, but cant use it as Fleet not offers all features you need yet. But if not using it, Jetbrains not spend more time doing it better 😄

Amper plugin working in all IDEs and using IntelliJ engine or?

[Joel Denke]

A little funny as I am just spending a lot of time improve gradle convention plugins and then realize its just maybe better go for Amper instead, but not sure yet 😄

[Joel Denke]

Btw does Amper allow condition things?
Like I have things like this:

if (pluginManager.hasPlugin(libs.plugins.android.library.get().pluginId)) {
        androidTarget()
      }

Where check if KMP should add android based on library or application android plugin 🙂

[Joel Denke]

@joffrey Amper plugin I cant find for Android Studio, is there a custom repo for that?

[joffrey]

Is Amper intented to be the new thing scaling up for Kotlin multiplatform and all IDEs? Or does that depend what the community input about Amper? Would like to not try using Amper and then suddenly Jetbrains is deprecate it and abandon it. Havent read about commitment from Jetbrains

We haven't formally committed on anything around Amper, because this is an experimental project right now. The goal is exactly to shape it based on the community's feedback, as you guessed.

[joffrey]

Amper plugin working in all IDEs and using IntelliJ engine or? Amper plugin I cant find for Android Studio

The Amper plugin should be available in Fleet and IntelliJ IDEA. Ultimately Android Studio also gets the plugin through IntelliJ. I'm not 100% sure, but I believe there should already be an Amper plugin in AS, albeit an old one. There should be a 1-major-version delay between IDEA and AS, AFAIK.

[Joel Denke]

Thanks! Hmm yeah probably not avaiable in Android Studio Hedgehog that I am using, maybe I need Iguana or next Canary, not sure. Missed out its there, just need to check which version I need to have. Not very clear with like version 2024.5.4 😄 WHy cant Android Studio be named 8.2.2 in same version as AGP 😄

[joffrey]

> Btw does Amper allow condition things?
It doesn't. We're making Amper configuration files as declarative as possible, and we're limiting this kind of extra logic. This is because we want these files to be 2-way toolable (the IDEs should be able to modify them easily, not only read them), and also we want the parsing/processing to be very fast.

That said, this condition seems a bit strange even in Gradle. Could you please elaborate a bit more about your use case for this?

[Joel Denke]

Hmm yeah in my case for this, you can have modules only using lets say iOS, Web and Desktop, but some of modules using same convention plugin. Then need to exclude target Android in KMP or things like mixing android Test vs androidUnitTest. So depending on which variant of Android library, test, application etc its not always applicable to apply KMP adding android target.
But theres other scenarios, like conditional parse libraries in repositories or such, and override versions dynamically, thats very common.
If not able to do if or some kind of filtering patterns, well then its much harder. For those cases I guess can use Gradle interop, but would be sad need to mix Amper and Gradle all the time.

[joffrey]

Ok thanks for sharing. I'm still not sure why you would use the same convention plugin for different project types. You could have a base convention plugin, and more specific ones (at least in Gradle), and apply the set of conventions you need for your particular project type. I believe that's how convention plugins are designed (they kinda define the type of your project)

[Joel Denke]

As of example I want to apply compose/kotlin multiplatform for Android application module but also on a Android library module.
But not apply same logic for both of them. I want same base setup for both of them, but not identical. Hard to explain 😛

[Joel Denke]

Maybe there is a better combination to solve that 🙂

[JulianK]

You should have one plugin for each type (app/library). They can than share the same code.
E.g. both ApplicationExtension and LibraryExtension inherit from CommonExtension, which you can configure.

extensions.configure<ApplicationExtension> {
    configureKotlinAndroid(this)
}
...
fun Project.configureKotlinAndroid(extension: CommonExtension<*, *, *, *, *>) { ... }

[JulianK]

Same with amper i guess, have two templates and include a common template in both