@sanity/generate-help-url

@sanity/generate-help-url is a minimal internal utility published by Sanity.io that turns a documentation slug into a fully qualified URL pointing at the Sanity help center (https://www.sanity.io/docs/help/). Instead of concatenating strings by hand throughout the Sanity ecosystem’s packages, contributors call generateHelpUrl(‘some-slug’) and get back a consistently formatted, TypeScript-typed URL every time.

The package is deliberately tiny — a single exported function with no runtime dependencies — but it plays an outsized role in Sanity’s developer experience: it’s the mechanism used to attach ‘Learn more’ links to warnings, errors, and deprecation notices thrown across the wider @sanity/* package family, keeping every one of those messages pointed at a real, maintained help article instead of a dead or inconsistent URL.

What You Get

• generateHelpUrl function - Takes a slug string and returns the corresponding https://www.sanity.io/docs/help/<slug> URL.
• Literal-type return values - Uses TypeScript template literal types so the return type reflects the exact slug passed in, giving callers compile-time-accurate URLs.
• Zero runtime dependencies - Ships as a tiny, dependency-free ESM/CJS dual build via @sanity/pkg-utils.
• Stable, versioned releases - Published via semantic-release with a changelog, so downstream packages can pin a known-good version.

Common Use Cases

• Attaching help links to thrown errors - Sanity Studio and CLI packages call generateHelpUrl inside error constructors so error messages include a direct link to the relevant help article.
• Deprecation warnings - Packages undergoing API changes use it to point developers at migration guides instead of embedding raw URLs.
• Consistent cross-package linking - Any @sanity/* package that needs to reference the help center reuses this utility instead of hand-rolling URL strings, keeping links consistent if the help center’s base path ever changes.

Under The Hood

Architecture The package has essentially no internal architecture beyond a single function in src/index.ts — a constant BASE_URL is concatenated with a generic slug parameter and returned as a TypeScript template-literal type. There are no internal layers, no state, and no side effects; the entire implementation is a handful of lines. The build is handled by @sanity/pkg-utils’ package.config.ts (extract disabled), which compiles the single source file into dual ESM (dist/index.js) and CJS (dist/index.cjs) bundles plus type declarations. There is nothing to break because there is no internal structure to change — the only ‘API surface’ is the one exported function, so any breaking change would be a change to its signature or output format.

Tech Stack Written in TypeScript, targeting a dual ESM/CJS output via @sanity/pkg-utils (Sanity’s shared build tool for its monorepo packages) with type declarations emitted separately. Testing runs on Node’s built-in test runner using the source-conditions loader rather than a separate test framework like Jest or Vitest. Linting combines ESLint with the eslint-config-sanity preset and Prettier for formatting; dependency and release automation come from @sanity/semantic-release-preset and Renovate. There is no database, no web framework, and no external service integration — the only ‘infrastructure’ is Sanity’s internal shared tooling for building and releasing packages consistently across its ecosystem.

Code Quality A single test file exercises the one exported function with a focused assertion, run via Node’s native test runner; there’s no coverage tooling, but the function’s total surface area is small enough that this test meaningfully covers it. Strict TypeScript typing and the template-literal return type give compile-time safety around the slug/URL relationship. ESLint and Prettier are wired into the lint script, and CI runs the test and lint scripts on push. Naming is clear and minimal. Given the package’s size, the test suite is proportionate rather than sparse, but it does not verify behavior with unusual slug inputs such as empty strings or special characters.

API Design The entire public API is one function with one required parameter, so onboarding cost is effectively zero — there is no configuration object, no class to instantiate, and no async behavior to reason about. The TypeScript signature’s generic slug type means editors can autocomplete and typecheck the exact URL literal produced, a small but genuinely nice ergonomic touch for a package this size. Documentation is limited to a short README usage example, which is sufficient given the function’s simplicity but offers no list of valid or known slugs, meaning callers must already know what slug to pass. This is a deliberately unglamorous, single-purpose helper rather than a novel design, so it scores modestly on innovation while still being pleasant to use for its narrow job.