Restrict plugin to test module
gnawf opened this issue · 4 comments
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.
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.
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.
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.
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.