Hi all. I've created a <GitHub project template> f...

# feed

[Big Chungus]

Hi all. I've created a GitHub project template for kotlin multiplatform libraries. It comes with a lot of preconfigured goodies to help you kickstart your projects. Star if you like it and don't forget to leave any feedback you might have in a form of Issue, PR or even DM here.

Currently it features the following:
• Native target grouping and shared sourceSets
• Wrapper library module that declares dependencies on all lib modules
• Uniform configuration via allprojects
• Local test module for shared test utilities (a helper function to run coroutine tests in common sourceSet included)
• Local sandbox module for easy library consumer side checks
• Publication control to avoid multiple publications for targets that can be built on multiple hosts
• ktlint plugin with automatic git-hooks
• refreshVersions plugin for better version control
• Main host for publications can be changed via gradle.properties#project.mainOS property
P.S. Commonizer breaks if I bump kotlin version to 1.5.0-M2, Might be something JB folks want to look into as a potential regression.

[Vampire]

I didn't look at it, but "Uniform configuration via allprojects" sounds very non-idiomatic if you care about that.
Better practice is to have convention plugins that you apply to the single projects manually.

[Big Chungus]

Interesting point. last time I've tried conventional plugins with build.gradle.kts, I kept getting resolution errors. Things might've changed by now. I'll give it another go 😄

[Vampire]

Or maybe you made some mistake? 🙂
Never seen resolution errors with convention plugins or I don't understand what you mean.

[Big Chungus]

Are we talking about the same thing? I meant this:

apply(from="another.build.gradle.kts")

[Javier]

That should not work

[Javier]

I think the id should be different

[Javier]

maybe apply(from = "another.build")

[Big Chungus]

Don't confuse it with apply(plugin="some.plugin.id")

[Javier]

but I don't know exactly, I should not use apply fun

[Javier]

Ah, yeah, you have right

[Javier]

Anyways, I should avoid both

[Big Chungus]

They both have their usages. Consider this case applying mpp plugin to all modules so you could set some common configs

plugins {
  kotlin("multiplatform") version "420.69"
}

allprojects {
  apply(plugin="org.jerbrains.kotlin.multiplatform")
  kotlin {
    explicitApi()
    jvm()
    js { nodejs() }
  }
}

[Vampire]

No, you are not talking about what is called a convention plugin. What you are talking about is a script plugin. There you for example cannot use a plugins block inside and don't have type-safe accessors available which makes them look clunky.

A convention plugin is a pre-compiled script plugin that you have in buildSrc or how I prefer it in an included build. In such script plugins you can use the plugins block and also get type-safe accessors for these. They look almost the same as when writing a normal build script. And you apply them just as other plugins in the plugins block of the respective projects.

[Big Chungus]

Yeah, was JUST reading about it 😀 That definitely looks cleaner, will refactor tomorrow.

[louiscad]

Me, working on changing #gradle-refresh-versions setup 🙈

[Big Chungus]

Any breaking changes on the horizon?

[louiscad]

Fortunately, no 😉
I am working on some code that will automatically replace the old bootstrap with the new setup way (a settings plugin + an extension). It takes a lot of time to do it right, but it looks like it'll be worth it.

[Big Chungus]

Can't wait to try it out!

[louiscad]

Tests and pair programming (aka. live code review) will try it first!

[christophsturm]

idea is pretty buggy with convention plugins. the workaround is to exclude buildSrc in the compiler paths

[christophsturm]

in  Settings->Build->Compiler->Excludes

[christophsturm]

(my youtrack ticket about it got set to private for some reason)

[louiscad]

I'd ask the folks to make it public again, or I'd create a new one and link it in the comments

[christophsturm]

I’ll just wait for it to be fixed

[Vampire]

Never had real problems with convention plugins in IJ. Granted nowadays I only use included builds and not buildSrc, but even with buildSrc I cannot remember significant problems.

[Vampire]

What problems did you have?

[christophsturm]

there were 3 problems: scratch files did not work, jps tried to build the files in buildSrc as kotlin scripts and failed, and “analyze code” analyzes autogenerated code in buildSrc. I have workarounds for the first two.

[Javier]

I am using them since 2019 with no issues. I use scratch files usually too.

[Big Chungus]

Did some refactoring (mainly gradle conventional plugins introduction, thanks to @Vampire) and added matrix-based GH actions to test and publish libs on all native hosts. This now warrants a v1.0.0 "release"

As always, feedback is most welcome.