Upgrade go1.25.5, Add Taskfile, golangci-lint configuration

[matoszz]

👋 hello resend friends - over in our mail sending repo we lovingly call newman I saw a Renovate PR to update to resend-go/v3 which was straight forward and easy to do. When reviewing the changelog between revisions, I happened to notice the package was on a now-unsupported version of golang - go support is basically for 2 major versions, the current being 1.25 and then the one prior, 1.24. So 1.23 is already out of support. Given that, I figured i'd open a PR to update the version to the latest (especially since 1.26 is about to come out).

While doing this, I noticed there wasn't a lot of love in terms of a basic linter setup so I added the most common one used, golangci-lint with a configuration file. Since it's often much easier to encode common tasks in a repo with some kind of helper (e.g. Makefile, Taskfile - most of y'alls repos are typescript so you're probably used to a package.json) I went ahead and added a Taskfile.yaml and put a basic blurb in the README.md linking to install instructions and usage. If there's some opinion about the use of Taskfile (or golangci-lint) I can remove them, but I would strongly encourage something exists in a similar fashion.

We're big users of Resend (and this go library) over at Openlane so i'm happy to continue to contribute if knowledge / experience with go tooling is a concern. Thanks!

---

Summary by cubic

Upgrade the project to Go 1.25.5 and modernize tooling. Adds golangci-lint and a Taskfile, updates CI, and standardizes errors and tests.

• Dependencies

  • Set go.mod to 1.25.5; Docker base to golang:1.25.
  • GitHub Actions bumped to v6; CI tests Go 1.25 only.
  • Added .golangci.yaml with common linters/formatters.
  • Added Taskfile.yaml with lint/format/test/build tasks; README includes quick setup.
  • Bumped testify to v1.11.1.

• Refactors

  • Standardized error handling (ResendError, ErrRateLimit, new sentinel errors).
  • Replaced ad-hoc string errors; tests use errors.Is and minor lint-driven fixes.
  • Added targeted nolint comments to keep existing public field names.
  • Minor code cleanups across services and examples to satisfy lint rules; no public API changes.

^{Written for commit 8ce96ee. Summary will update automatically on new commits.}

[cubic-dev-ai]

1 issue found across 43 files

Prompt for AI agents (all issues)

Check if these issues are valid — if so, understand the root cause of each and fix them.


<file name="audiences_test.go">

<violation number="1" location="audiences_test.go:43">
P2: Instead of suppressing the revive linter warning with `//nolint:revive`, fix the argument order. Testify&#39;s `assert.Equal` expects `(t, expected, actual)` but the code has `(t, actual, expected)`. When tests fail, this will cause confusing error messages showing expected/actual values reversed.</violation>
</file>

---

Since this is your first cubic review, here's how it works:

• cubic automatically reviews your code and comments on bugs and improvements
• Teach cubic by replying to its comments. cubic learns from your replies and gets better over time
• Ask questions if you need clarification on any suggestion

_{Reply to cubic to teach it or ask questions. Re-run a review with @cubic-dev-ai review this PR}

[cubic-dev-ai]

P2: Instead of suppressing the revive linter warning with //nolint:revive, fix the argument order. Testify's assert.Equal expects (t, expected, actual) but the code has (t, actual, expected). When tests fail, this will cause confusing error messages showing expected/actual values reversed.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At audiences_test.go, line 43:

<comment>Instead of suppressing the revive linter warning with `//nolint:revive`, fix the argument order. Testify&#39;s `assert.Equal` expects `(t, expected, actual)` but the code has `(t, actual, expected)`. When tests fail, this will cause confusing error messages showing expected/actual values reversed.</comment>

<file context>
@@ -34,17 +34,20 @@ func TestCreateAudience(t *testing.T) {
 	}
-	assert.Equal(t, resp.Id, &quot;78261eea-8f8b-4381-83c6-79fa7120f1c&quot;)
+
+	assert.Equal(t, resp.Id, &quot;78261eea-8f8b-4381-83c6-79fa7120f1c&quot;) //nolint:revive
 	assert.Equal(t, resp.Object, &quot;segment&quot;)
 	assert.Equal(t, resp.Name, &quot;Registered Users&quot;)
</file context>

[matoszz]

typical AI response 🙄 - this revive linter error is due to the variable naming; variables in go should be named like this resp.ID instead of resp.Id so the revive exception is due to the naming rather than the argument order

[drish]

Can we also include 1.24 ?

[drish]

hey @matoszz, thanks a lot for you contribution.

I'm good with removing support for: 1.21, 1.22, 1.23 versions and updating mod to 25, I wonder if you could update your PR to tackle only those changes specifically so that I can merge that quicker ?

For the tooling updates - I'd ask you to open a new PR tackling only those, and we could discuss those changes specifically on that new PR ? I agree that the current setup isn't the best, but my personal preference is to keep the project as "vanilla"/standard as possible, that would basically mean adding the standard go vet, staticcheck, gofmt check, govulncheck as part of our CI as they currently aren't there, but I will ask what other people from the core team think too.

[matoszz]

@drish sure thing - I had kind of suspected after going down that rabbit hole that I might have been changing too many things at once 😆

Regarding the go vet, go fmt, etc., I'd suggest simply using the linter configuration as this will accomplish roughly what you're wanting without the need to maintain a huge sprawl of build steps and commands but obviously that's up to your team to decide. We do a lot of go development over at Openlane if you were interested in checking out some of our repos, I think we follow pretty good practices.

I'll open another PR here shortly with just the version changes.

[matoszz]

Closing in favor of #96