What do you feel about deprecating these? GH code ...
# kotest-contributors
e
What do you feel about deprecating these? GH code search shows no usages outside Kotest. I don't really see the point in them either to be frank. If you're testing Kotlin-code, there's no reason to assert for "truthy"/"falsy"?
s
GH is only going to show us public usage. While I agree they're probably pointless, what's the gain in removing them?
e
Just less stuff in the API. I think we should try to minimize it when possible. Maybe we could create a discussion and link it from the deprecation to ask for feedback on removing it?
s
Sure lets do that. I would like to consider moving assertions into its own project. I've brought it up before and gone back and forth, but I feel like the cadence of property / assertions / framework move differently.
e
Do you want it in separate repositories or just separate releases?
s
repos I think, then the build times would be much nicer too
When I'm making framework changes, it's nice to not have the baggage of compiling all the assertions stuff in 15 targets. I know we could make gradle build changes to do that too, but it might be nicer to just have it all separated out? Thoughts?
I've added a discussion for it here: https://github.com/kotest/kotest/discussions/4056
👍 1
e
In general I feel it's easier to maintain fewer repos. Kotest extensions are a bit of a pain to keep up-to-date now, but on the other hand they don't actually need to change that often, so maybe it's a sign that we would've spent effort for little gain by keeping them in the main repo? One concern I had was seeing compatibility changes across framework/assertions/property, but as you say we don't really do things that have big impact across those boundaries. Regarding releases, we could just do them as fast as we'd like even with everything in same repo. It's like when Kotlin does a release, sometimes there's not really anything new that affects us, but other times there are. I guess it's currently the same users who only use assertion, or only property-testing, etc..
s
You're right on releases we can do them at any pace we want. Maybe there's value in knowing that the core framework module is not advancing. Right now if we do 5.x.y it's harder to know if you should upgrade or not. I think the project is too large though, and trying to work through the code base is a slog. We should reduce the number of modules as well. I think the engine project could drop down to 5 modules instead of the two runner modules + 3 plugins + 6 others.