Skip to content

No vendor SDK in the core

This module has no third-party dependencies at all. Not few — none. A depfootprint guard test asserts it on every run, over both the contract and the conformance harness.

What that buys a consumer

Accepting a chatplatform.Reader in your function signature costs you this module and the standard library. It does not cost you a Discord client, a WebSocket stack, a JSON library or a rate limiter.

That matters most for the code furthest from the platform. A moderation scorer, a retrieval layer or a test helper that takes a Reader should not drag a gateway client into a build that never opens a socket.

What that buys an author

A provider is your module. Registering under a string key means a platform this module has never heard of ships without anything being contributed here, and without waiting for a release.

The rule that keeps it true

Every platform client lives behind a provider module boundary. A vendor SDK import anywhere outside its own provider module is a defect, and the guard test names the offenders individually so the coupling cannot creep back in:

var forbidden = []string{
    "github.com/bwmarrin/discordgo",
    "github.com/disgoorg/",
    "github.com/slack-go/slack",
    "gitlab.com/phpboyscout/go/chat-platform-",   // sibling providers
    "github.com/gorilla/websocket",               // transports belong in providers
    ...
}

Provider modules carry the mirror of it: a provider may depend on its own platform's SDK and no other's, and never on a sibling provider.

The one place it costs something

Sentinel errors use errors.New from the standard library, where the wider phpboyscout toolkit prefers cockroachdb/errors.

That is a deliberate inconsistency. A zero-dependency graph is worth more here than uniformity of error package, because it is the property that lets a consumer accept a Reader without inheriting anything. Providers are free to use whatever error library they like — they already have dependencies.