Future directions of rules_kotlin

[git-str]

Background
The current Kotlin ruleset bootstrapped the Kotlin language into the Bazel ecosystem. It helped many people start using a great new language with a great new build tool. We're very appreciative of the effort the maintainers put into this endeavor.

Unfortunately, the ruleset has not seen any significant development or maintenance for several months. This has caused it to fall significantly behind the Kotlin language and its toolchain. Google recently started supporting Kotlin for internal teams as a first-class language. As part of this effort, we have created an internal ruleset for Kotlin and we are committed to improving and maintaining it. This ruleset currently supports Kotlin 1.3.20.

The two rulesets share some commonality between rule names and attributes, but have entirely different implementations. Google has volunteered to take over maintenance and development work for rules_kotlin. We are committing to partnering with the community to drive the Kotlin rules forward. The team is motivated to take on this extra responsibility because of the importance of Kotlin for the Bazel ecosystem and the importance of its interactions with the Android ruleset which we also maintain.

Proposal
The external rules only support up to Kotlin 1.2. There are ~20 open issues and ~10 open pull requests. Upgrading to Kotlin 1.3 is important for the community, but it is a non-trivial upgrade and previous attempts ran into blockers. Google's internal ruleset has Kotlin 1.3 support and is generally available to all Google engineers. The external and internal rule implementations have no commonality making supporting both impractical.

The external rules have interesting features (eg: friend modules, java worker support, etc) that we would like to provide internally. The internal rules also have nice features such as interface jar (ijar) compatible compilation avoidance that would be beneficial to the community.

We would like to find a way forward where Google engineers and external developers use the same ruleset for Kotlin backed by the implementation Google has been maintaining internally.

High Level Roadmap

• Branch master into legacy-1.2-support.
  • This branch will not be actively supported, but we will accept reasonable bug-fix pull requests.
• Open source the Google Kotlin rules into a separate branch in rules_kotlin.
  • Both rules sets (legacy-1.2 and kotlin-1.3) can coexist in one WORKSPACE.
• Document the differences between the rule names and attributes between the two versions.
• These differences are pretty minimal. Many users should be able to switch over easily.
• Propose timelines/roadmaps to address any feature gaps.
• Merge the newly open sourced rules into master.
• Implement missing features in master.

We would like the community's input and feedback on this plan by March 1st, so we can either start work on the open sourcing of the internal Kotlin rules or go back to the drawing board. We are very excited at the opportunity to have a single master Kotlin ruleset that internal and external Google projects can use as well as supporting the Bazel community. We're looking forward to working closely with all of you.

[cgruber]

+1000. Please. This is what I've been hoping for since December. If there is any way I can help, Please don't hesitate to ask. We're pushing a lot of boundaries in both our internal kotlin experiment at Square, as well as our bazel maven integration.

Other clarifications could include: the posture of the project in accepting pull requests, and what work/prep needs to be done to make a pull request useful (given that all of these will end up having to be tested against google3/ I know well how hard that can be).

I'll leave actual feature requests off this, as they should be in separate issues, and really it's hard to know what's needed until we see these rules. But yes, please, absolutely do this.

[cgruber]

Also, please accept at least some PRs for the legacy rules, as some of the PRs are necessary for using the rules at all with recent versions of bazel (e.g., the thing with no-sources libraries using exports, etc.)

[rohansingh]

I'm on the same page as @cgruber. Having something that works with 1.3 is much better than having nothing.

Knowing that the publicly available rules are the same ones being used internally at Google would also give me a lot of peace of mind. That's actually way more important to me than any particular feature in the current or future rules.

[davidsantiago]

I want to write and add my support for this plan of action (and also express my gratitude to the original creators and maintainers of this rule set). The one thing I'd say is the sooner we can get something, anything, the better. I'm currently in the midst of converting a project to Bazel, and maven/misc issues have slowed me to the point where our Kotlin 1.3 migration happened, and now we're left without working kotlin rules, as far as I can tell.

[trevorsummerssmith]

+1000 as well. We are a small startup currently using rules_kotlin. We fully support this proposal and look forward to testing and contributing to the new direction. Thanks for the work here!

[artem-zinnatullin]

👍 No objections from Lyft

We're especially looking forward for this "The internal rules also have nice features such as interface jar (ijar) compatible compilation avoidance that would be beneficial to the community."

I hope community will be able to efficiently collaborate on top of what you'll publish and contribute the missing pieces.

Thanks for working on that ❤️

[git-str]

Thank you all for the positive feedback and the offer to collaborate with us.

I'm convinced that together we can take the Bazel Kotlin rules to the next level. We are actively working on our roadmap and will publish it in the next several days to get your feedback.

[jgavris]

Looking forward to it!

[cgruber]

Still looking forward to it! ;)

But seriously, we're really quite constrained until we can see the shape of your plans, so we can adjust our plans (what to work on on our own, what to hack up until you've got better stuff in place, knowing what we can collaborate on). Please don't keep us in TOO much suspense.

[cgruber]

Related to the roadmap, I've definitely gotten nibbles about kotlin-native support, so at least for some of the teams that will follow us down the maven rabbit hole, kotlin-native specifically, and kotlin xplat more generally, will become an issue probably this year. Hopefully the roadmap will incorporate this (or at least incorporate a way the community can join in to help deliver on these needs, if it's beyond the immediate scope of the team).

[cgruber]

Could we please get an update? We're all pretty eager to move into the future, but it's frustrating not even knowing the plan and hoped-for timelines. It makes it very hard to plan.

[Globegitter]

Gentle ping @10-10-11

[pardom]

Also, +1 from Instacart as we are currently exploring Gradle alternatives.

[git-str]

Thanks for your patience. It took longer than expected to put together the new roadmap for rules_kotlin.