Restrict plugin to test module

[Franklin Wang]

Right now, if I apply this plugin to a module then it will affect the code under src/main.

This is less than ideal for code that ends up going into a production backend e.g. can accidentally expose internal values if the error message somehow surfaces to the user.

[Brian Norman]

While I agree that this is a concern, there are use cases for this plugin that do extend into production environments. Also trying to apply some sort of default without end user control will be impossible given how configurable source sets are in Gradle. I'm not aware of any other compiler plugins that allow customization of which source sets they are applied to but I can look for some and see if a similar pattern can be applied here.

Just as a secondary thing though, are you applying the plugin with the default of kotlin.assert transformation or are you limiting it to just test assert functions? This could be a way you could limit it today, so that it only applies to functions which exist in your test source sets.

[Franklin Wang]

While I agree that this is a concern, there are use cases for this plugin that do extend into production environments.

Sure, I can agree with that. It's actually quite useful for debugging main locally if a require or assert fails, it's actually how I found out that this runs in non-test environments. I think it would be good to disable it for release builds though.

Also trying to apply some sort of default without end user control will be impossible given how configurable source sets are in Gradle.

Ah, perhaps this should be an opt in thing then? Perhaps a warning of some sort in the README that this would apply to all source sets. I was definitely not aware this would apply to all my source sets until recently, and I would definitely at least like to know. One more line for installation shouldn't hurt too much? But it would be a breaking change for anyone who previously had it installed…

Just as a secondary thing though, are you applying the plugin with the default of kotlin.assert transformation or are you limiting it to just test assert functions? This could be a way you could limit it today, so that it only applies to functions which exist in your test source sets.

Right, so you're correct, for the most part I run it on kotlin.assert which shouldn't be enabled in production.

I actually found out it about this behavior in a Kotlin Multiplatform project because kotlin.assert doesn't exist as it's a JVM specific thing, for some reason. I then configured the plugin to transform kotlin.require because that is multiplatform. Then the kotlin.require statement tripped up in src/commonMain and spit out the power assertion output.

[Franklin Wang]

Just another thought, if I have this code

            val thing: Any = 1
            assert(thing is Int)
            assert(thing % 2 == 0)

It won't compile because we don't smart cast as assert is not guaranteed to run.

In that case, someone might want to use kotlin.require and enable this plugin on kotlin.require and do

            val thing: Any = 1
            require(thing is Int)
            assert(thing % 2 == 0)

Thing is, they've now unknowingly enabled it for their entire project. So any require will print out all the objects associated.

[Brian Norman]

In that case, someone might want to use kotlin.require

This is where I would recommend using kotlin.test.assertTrue instead if you are looking to keep this restricted to test source set. I'm still looking into clean ways to maybe exclude Gradle source sets and I've got a few promising ideas but haven't had the time yet to test them.