Mockk: Discussion: what are the (near future) plans for MockK?

[erikhuizinga]

This is not a MockK issue, but more a question/feedback to @oleksiyp (MockK's developer). I hope more people in the community feel this way. If so, please comment or give this issue a 👍. Or otherwise let me know what you think.

First of all: thanks for MockK. I'm very happy with it. I hope it will continue to add value to the Kotlin community.

Also, please note that I know you've commented on many issues already that your time is limited for good reasons. I think it's most important that you decide for yourself when to do what with your time. Please never change that.

Now the feedback: I noticed that it's been quite quiet around MockK's developments. It's been more than half a year since the current latest release (v1.9.3) was released, while previous releases happened on about a monthly basis. In the mean time some developments have taken place: new issues and PRs were opened, addressed and closed for various things. You introduced a stale issue management bot to help you prioritise open issues. But it all went a little bit slower than before, which I understand considering that you only have 24 hours in a day to spend on whatever you decide is important. I like MockK a lot and therefore it's a pity that so little (visible) development happened since the last release. Also, the developments on the Kotlin language and official stdlib extensions, like coroutines, continue to move forward. I'm afraid MockK will lag behind at some point. And in general, I wonder what's going on with MockK and where this project is going. Therefore I want to ask you to clarify the following questions.

What plans do you have for MockK? What do you need to keep actively developing on / maintaining MockK? Do you still want to be this project's lead developer? Do you need more time/motivation? Do you need maintainers? Do you need anything else?

Please, see this issue as a central place where you give the MockK community feedback about what you want, what you need, or whatever ideas you have. Or maybe ask whatever questions you might have yourself.

I'd love to help by working on MockK myself, but I think I neither have the time nor the required skills for it.

What might be a bit of motivation is the upcoming KotlinConf: wouldn't it be awesome to have some new features/bug fixes done in time for the conference, so that it's clear that MockK is still a valuable contribution to the Kotlin community? Please let the community know what you need to make this happen. I think we all want the same? Please let the community know how we can get there.

[oleksiyp]

Happy MockK is growing and helping people.

Currently, my interest is shifted.
Although I am trying to follow what's happening.
If some major issue apear I will react(alike new Kotlin version incompatibility, JVM)

I would be happy to have somebody else regularly committing to MockK. Or even collect some money and hire somebody. I put a banner in regards to sponsorship on the main page for this purpose. Believe more user community grows more chances this is going to happen.

The biggest problem I see is that most of the issues appearing right now are corner cases and require a lot of effort to fix, great effort to learn for newcomers and usually don't give a lot of benefits. That's why it is hard to devote time and find somebody who helps to fix something. The codebase itself is pretty complex.

[erikhuizinga]

The codebase itself is pretty complex.

That's an interesting fact. Would it be worth the effort to simplify the codebase, and would that help?

[oleksiyp]

To some extent refactoring is possible, but generally, there are a lot of complex things happening under the hood. I tried to record YouTube videos to describe tricks on the way, but after a few realized it is not the best approach.

I also tried to engage people to tell what's complex they face while trying to fix something, do PR. Generally, belive a simple outcome is that wrongly picked up task may become a nightmare to implement.

For example, the issue with infinite recursion in ConcurrentHashMap actually may result in creating a copy of a series of JDK classes as a solution. You need pretty big courage to come up with this and some knowledge to implement.

That's why the first thing to do is to create a system of task/issue/bug categorization and categorize tasks. Maybe write for each issue it's prototypical solution.

[Raibaz]

I'd also like to help keep the project active, as I think it's a very valuable tool for the whole kotlin community. I can start lending a hand on the easier stuff while I get more accustomed with the codebase, so yes, I agree that categorizing tasks may be a good start to facilitate contributions.

Let us know how we can help :)

[erikhuizinga]

@oleksiyp this is a complex situation for MockK.

It's only logical that while the project progresses towards a more and more feature complete product, the issues that are left implicitly become more complex and/or are about edge cases. They're harder to diagnose and fix.

This might be a sign that it's time to think about what the lib's client API and the developer's maintenance API (code base) look like?

Another practical question:

Let's ignore the existing 'edge case' / 'complex' issues. What if new issues arise because the Kotlin language evolves (e.g. new releases with new features, or current features being deprecated/obsoleted)? Do you think you can make time to support Kotlin language changes when necessary?

[oleksiyp]

I checked all opened issues(around 44) and added them to the following projects:

• Critical to fix: https://github.com/mockk/mockk/projects/3
• Low hanging fruits: https://github.com/mockk/mockk/projects/4
• Features: https://github.com/mockk/mockk/projects/2
• Extra hard: https://github.com/mockk/mockk/projects/5

Beleive the next version should focus on the first category.

There are as well 77 issues filtered out by stale bot: https://github.com/mockk/mockk/issues?q=is%3Aissue+sort%3Acomments-desc+is%3Aclosed+label%3Astale

[oleksiyp]

Cross-referencing #356 . Don't hate bot :angel: After all, triaging 44 hot issues is kind of easier than 120

[oleksiyp]

Triaged everything that was closed by stale bot.

Mockito https://github.com/mockito/mockito/issues has 230 opened issues which is 31%, while mockk has 82 opened issues which is 35%. So not everything is so terrible.

[Raibaz]

Thanks a lot for doing this, it's been very helpful!

[cjbrooks12]

Thanks, everyone for all your hard work and dedication to this wonderful project! It's really encouraging to see the community stepping up to support Mockk like this.

[pusolito]

I'm also a really big fan of mockk and would love to see continued progress on it. In particular, I'm wondering what the plans are for better JS support and Kotlin 1.4-M1. The latter has a new compiler backend (IR) that isn't compatible with the current one. That means any project that depends on mockk today won't be be able to adopt the new compiler until mockk provides an upgrade path (say on a separate branch) or they fork :(.

[oleksiyp]

I have very good news regarding mockk. Seems gradle build that was failing due to gradle bug is resolved
(this is currently in "develop" branch) .

Gradle/Android plugin/IDEA is known for it's aggressive update policy and every time I tried to start fixing some bugs I bumped into the wall of this Gradle issue.

But now it seems it is all in the past. I updated versions of dependencies and going to release new mockk version soon.

[oleksiyp]

@pusolito in next release I am going to abandon 1.2.x branch and later will add 1.4.x

[pusolito]

@pusolito in next release I am going to abandon 1.2.x branch and later will add 1.4.x

This is awesome!! Thanks for the update. What does this mean for #100?

[oleksiyp]

Not sure about it right now. First I'd like to have stable release procedure

[oleksiyp]

Released https://github.com/mockk/mockk/releases/tag/1.10.0

[cdw047]

@oleksiyp what are the next issues that you are planning to fix. I got 6 months working on kotlin and mockk so looking to contribute for some easy stuff first.

[oleksiyp]

@cdw047 for something to start with I created this project https://github.com/mockk/mockk/projects/4

[erikhuizinga]

It might be a good idea to close this issue and create one or more new issues / projects:

• One for an overview of how to contribute. Adding a CONTRIBUTING.md file and clearly pointing to it from the readme might be a solution too.
• One for a roadmap/overview of (near) future plans.
  
  
  
  • For example, with Kotlin 1.4 at the doorstep, development of MockK might need to move forward to fully support v1.4 when its stable release becomes available.
  
  

(Some of) these issues could point back to this issue, and they could be pinned so they stand out. I'm not sure if this issue still contributes to MockK. I think that this issue's goal has been achieved:

• We've found out that many people are happy with MockK.
• The developer, despite being a busy person, wants to actively develop MockK.
• There are projects with easy to very hard issues.

If the MockK project is organised to have handled these points, I think that we can close this issue.

[pusolito]

Any update on 1.4 support?

[oleksiyp]

Any issues with 1.4 support?

[pusolito]

Is it supported yet? I thought there was only support for up to Kotlin 1.3x.

[oleksiyp]

Only way to confirm to try it out

[pusolito]

Sorry, I meant updates on supporting the new IR compiler for 1.4. I'd love to upgrade Doodle and Measured to the new compiler to improve JS bundle size. This requires IR support from Mockk.

[rmaclean-ee]

I am using it with 1.4 and all is working for us.

[pusolito]

@rmaclean-ee,are you using the new IR compiler backend? This would require Mockk be built with Kotlin 1.4. But it looks like the latest only supports 1.3.61.

[erikhuizinga]

@pusolito good questions, thanks for pointing this out. I suggest that you create a new issue to investigate and discuss the Kotlin 1.4 IR compiler support in MockK, because this seems quite specific so it might be better kept in its own issue.

[Raibaz]

Pinging this issue because we have a new maintainer (myself :))

I'm going to try and do some additional triage on open issues; I'd like to tag the ones that look relatively easy as "good-first-issue", hoping to draw some contributions, and to try and reduce a bit the number of open issues.