designing-internal-boundaries

$npx mdskill add supabase/supabase-go/designing-internal-boundaries

In Go the package is the only compiler-enforced encapsulation boundary. File boundaries are decorative, so any file in a package can assign any unexported field declared anywhere in that package. A contract enforced only by convention is not enforced, causing maintainability issues as the amount of source code in a package increases (whether by line count or file count), so should be considered a design smell.

SKILL.md

.github/skills/designing-internal-boundariesView on GitHub ↗
---
name: designing-internal-boundaries
description: Guides the design of internal type contracts in respect of immutability and encapsulation. Enhances codebase maintainability by separating concerns in a manner that is compiler-enforced, both for internal state as well as immutable values returned to callers alike. Use when creating or reworking types, when adding machinery (e.g. parsing, caching, transport, crypto), when naming or splitting an internal package, when writing constructors or defensive copies and when deciding whether a test is external or in-package.
---

In Go the package is the only compiler-enforced encapsulation boundary. File boundaries are decorative, so any file in a package can assign any unexported field declared anywhere in that package. A contract enforced only by convention is not enforced, causing maintainability issues as the amount of source code in a package increases (whether by line count or file count), so should be considered a design smell.

Exemplars include: `postgrest/internal/http` and the `auth/internal` packages (`token`, `key`, `cache`, `profile`, plus `testkit` for shared fixtures).

Highlights of good design:

1. **One concern per package and let naming police that.** If no single plain word names the package then it probably covers multiple concerns, therefore should be split into multiple packages. A coined compound name is usually a design smell.
2. **A contract-carrying type is a one-field wrapper.** `auth.Claims` is `struct{ inner token.Claims }`: the inner type lives in an internal package and its fields are unexported, so only that package can touch them. Public accessors forward to `inner`, carrying the consumer-facing docs and no logic. Contract-free types stay ordinary structs (`auth.Error` keeps exported fields).
3. **Constructors are the only source of values.** The internal package exports them, and the public package never builds or mutates inner values. Reassigning `inner` still compiles - never do it.
4. **Defensive copies live with the fields they protect.** Clone maps and slices in the owning package's accessors, never in forwarders. Document shallow clones.
5. **Policy stays public, machinery goes internal.** Sentinels, error shaping, routing and fallbacks stay in the public package, while HTTP and credentials are injected as closures - the error model is defined once.
6. **Cross boundaries by value.** A shared pointer hands read-only code a mutable alias (the `*url.URL` lesson).
7. **Tests are external by default.** `*_test.go` files are `package x_test`. In-package tests live only in `*_internal_test.go` files, for behavior a boundary genuinely hides. Shared fixtures go in an internal test-support package, never into widened production API.
8. **Know when to stop.** Single-function wire carriers and contract-free types need no boundary. Enforce stated contracts, not ceremony.

More from supabase/supabase-go

SkillDescription
auditing-tool-currencyGuides auditing the repository's externally sourced, version-pinned tooling against canonical origins - the GitHub Actions pins, the Go tool module under tools/go, the npm tool module under tools/node, the pinned Supabase CLI and the Go consumer floor. Use when asked which tools could be upgraded, whether pins are stale or to prepare an upgrade report or plan. Audit and report only: applying a bump is the changing-build-and-continuous-integration skill's territory.
changing-build-and-continuous-integrationGuides changes to this repository's build, module and CI machinery rather than the SDK's own code. Use when touching any go.mod, the go.work workspace, the scripts folder, GitHub Actions workflows, the pinned tool modules under tools or the spell-check configuration - including adding a new module, taking on a new dependency or bumping a Go or tool version. Covers workspace wiring for unpublished sibling modules, the published Go version floor versus the CI toolchain, digest pinning, the first-party-actions-only policy and the rule that CI jobs run the same scripts developers run locally.
designing-public-interfacesGuides design of this SDK's public API surface. Use when adding, renaming, removing or reshaping any exported identifier in any module published as end-user, consumer-facing interface - whether that module be existing or new to the published surface area. Includes functional options, domain client accessors, error model, sentinel errors, error struct types, exported fields, the accessor pattern, constructor signatures and naming policy.
recording-decisionsGuides when a development decision earns a decisions.md entry and how entries are proposed and written. Use when a design choice is made, changed or reverted during any task. Never write decisions.md unprompted - a candidate entry is proposed in chat through the three-part falsification test (maintainer question, answer-from-source attempt, why the answer fails) and only a commissioned entry is written. Covers the false-trigger list and the What/Why authoring rules.
writing-changelogsGuides the writing and editing of changelog entries in the per-module CHANGELOG.md files. Use when a user-facing change needs an entry, when drafting or reshaping an Unreleased section, or when reviewing entries at release time. Covers the type headings, the entry shape and the succinctness bar - what an entry says and what it leaves to the docs.
writing-commentaryGuides the content and style of all comments - Go doc comments on exported or internal identifiers, package overviews in doc.go, inline comments and comments in scripts, workflows, SQL and configuration files. Use when writing, editing or reviewing any comment on any surface, including comments authored in passing while implementing something else. Covers audience focus (API consumer versus codebase maintainer), contract-first phrasing and where rationale, history and cross-component notes belong instead.
writing-examplesGuides the creation, update, merging and deletion of examples - the runnable Example functions that render on pkg.go.dev, the code snippets inside doc comments and the example programs under examples/. Use when adding an example, reworking one or deciding whether an existing example is replaced, upgraded, folded into a sibling or removed outright. Covers the removal test and when an example earns its place.