Back to maintaining slack-go

When I originally wrote the slack-go library years ago, I never imagined the journey it would take me on. I'm excited to share that I've returned to actively maintain slack-go, and I want to bring you along for the ride.

How it came to be

The very first commit happened in January 2015. It is wild do think it has been 10 years since that first commit.

commit 8258160238a6951085878bd28d90f83329957d76
Author: Norberto Lopes <REDACTED>
Date:   Fri Jan 9 21:14:04 2015 +0000

    Initial commit
  

Life, as it tends to, took me in different directions, and I stepped away from maintenance responsibilities, handing them over as I moved on.


Last year, I joined incident.io, which uses the library (with its own fork), and then I noticed the library facing some maintenance challenges. We've all been there – maintainers have lives, jobs, and other commitments. During one of those periodic "Is this still maintained?" discussions, I found myself stepping back in.


So, here we are. I'm back, and I'm excited to be here (plot twist: this actually happened in January 2025 but I'm only now writing this post).

What's happened so far...

Since I've returned, I've been working on a few things, which back I messaged as intent to the community, back in January, as follows (added emoji as progress):

  • ✅ re-familiarise myself with current state of the codebase
  • ✅ go over the open PRs, accept/drop what makes sense and isn't a breaking change
  • ✅ issue a new release with those changes(v0.16.0)

Next up:

  • ✅ go over the breaking change PRs and decide what should be in/out
  • 🏗 issue a breaking change release

And finally, I'll take stock of what's missing, including any major gaps, and try to fill those.


Let's go over the specifics of what I've done so far.

First release back: v0.16.0

For the 0.16.0 release, I focused primarily on non-breaking changes, though I should note there were a couple of changes that could potentially introduce breaking changes in rare circumstances.


The highlights include:

  • Added Slack AI & Assistants compatibility
  • Fixed several issues with Assistant Prompts, rich text emoji elements, and ScheduleMessage functionality
  • Added the ID() method to the Block interface (note: if you were using only what we provide in the library, this is a non-breaking change)
  • Added deprecation notices for legacy functionality like rtm.start

The full release included contributions from numerous community members, and I'm very grateful for their help.


Since then, I've tried to keep up with the PRs and issues that have come in, and I'm excited to see the project moving forward.


Let's take a look at what that looks like.

Next release changes

Since the v0.16.0 release, I've been working on merging a few changes:

  • New Features

    • Added markdown block support
    • Made multiple file upload methods public to improve usability
    • Added filter support in MultiSelectBlockElement
    • Added support for unmarshalling markdown blocks
  • Fixes and Improvements

    • Fixed function execution events to accept interfaces not strings
    • Improved test cases for marshaled params
    • Fixed race conditions in slacktest
    • Added proper error handling for exceeded message limits
    • Added support for rich_text_value in BlockAction
  • Maintenance

    • Configured Dependabot to maintain GitHub Actions
    • Bumped testing dependencies including golangci-lint to 1.63.4
    • Updated testing Ubuntu runner to 24.04
    • Simplified error messages and improved consistency

These changes are currently in master and will be part of the next release v0.17.0.

What's next?

There's still plenty to do. Here's what I want to get to as quickly as possible:

  • Release v0.17.0: it will include breaking changes that have been carefully considered, including hard deprecations that are necessary for the library's evolution.
  • Do a gap analysis: after the breaking changes release, I want to take stock of what's missing and identify any significant gaps in functionality that need to be addressed.

The best way you can follow progress in future is by checking the GitHub Releases page.

A personal note

Coming back to this project reminds me of something important: open source is as much about community and continuity as it is about code. Libraries like this one may serve as critical infrastructure for countless applications, therefore I don't take this maintenance burden lightly.


And there's also something special about witnessing how a project I started a decade ago continues to grow and evolve, even when I'm not actively involved. It's a testament to the power of open source and the community that surrounds it.


One cool thing I didn't quite expect was the changes in Go itself. Let's talk about that next.

Changes in Go

Since I started looking at Go again as part of my return to maintaining the library, I've had some interesting realizations.


Go has come a long way in the last 10 years, and I think the Go team should be quite proud of their work. Of course, some things remain challenging – I'm still not a fan of nil [1] and doubt I ever will be!


On a positive note, I've been pleasantly surprised by several improvements that I hadn't been actively tracking:

  • Paths are now better organized (GOPATH, GOROOT, etc.)
  • Go test caching makes development workflows much smoother
  • Error wrapping is quite neat
  • The module system has added numerous helpful features

There have been a few surprises too. I didn't expect to see slog introduced into the standard library, but perhaps that makes sense for standardising logging approaches.


Coming back after so long gives me a unique perspective. I notice both the evolution and the constants in a way that's harder to appreciate when I'm immersed in daily use. It's been fascinating to witness the Go ecosystem's maturation through looking back.

Final thoughts

I'm quite excited to be back maintaining slack-go. And for those that have contributed in the past 10 years, and those that are still contributing: THANK YOU!


Here's to the next chapter of slack-go – let's go!

Notes

[1]: I've been writing a lot of rust, and I must say, having access to Result<T,E> and Option<T> types is a game changer. I wish Go had something similar.
~ fin ~