preview-rpc Is What Happens When Boilerplate Learns to Get Out of the Way

Aiden Bai's TypeScript starter makes the local preview feel like an installed package, then ships the same code through a strict, minimal build pipeline.

9 min read · aidenybai/preview-rpc

A black ink editorial illustration of a workbench where a blank package identity is being swapped for a finished one. Source files branch into multiple outputs, showing how the repo turns one live codebase into a preview environment and several publish formats. The image explains that the development loop and the release loop are intentionally the same machine. — The package stops feeling fake once the sandbox consumes live source and the build pipeline starts producing real artifacts.

A lightweight RPC library for preview environments.

Aiden Bai, Creator/Maintainer · preview-rpc GitHub Repository

Key Takeaways

preview-rpc treats the preview loop as the product by wiring a kitchen-sink sandbox directly to live source.
The placeholder rename ritual is not decoration, it forces the repo to feel like a real package from the first edit.
tsup, publint, Vitest, happy-dom, and Biome form a compact pipeline that covers shipping, validation, and speed without a sprawling toolchain.
It is best for library authors who want tight feedback and multiple bundle formats, not for teams who need a full docs stack inside the repo.

Most starters ask you to imagine the finished library later. preview-rpc flips that order. The kitchen-sink sandbox imports the code through a Vite alias, so the thing you are editing already behaves like something you could ship.

The point is not that the repo has two workflows. The point is that it makes one source tree serve both the edit loop and the ship loop without feeling like a compromise.

Aiden Bai keeps making tools that disappear into the background

That line is small on purpose. It reads like the whole project in miniature: narrow, practical, and allergic to ceremony. The repo feels like a distillation of Aiden Bai's tooling style, where the fastest path is usually the best one if it still leaves room for control.

The build pipeline splits dev truth from publish truth

The build side is disciplined rather than elaborate. tsup takes the source once and emits the formats library authors actually need, including ESM for modern bundlers, CJS for older consumers, and an IIFE build for direct script use. The config also bakes version data into the build and adds license banners automatically, which keeps the published package honest without making the source tree noisy.

A black ink split illustration showing two starter kits. One side is crowded with extra scaffolding, stacked notebooks, and tangled cables, while the other side is a compact bench with one source tree, one preview sandbox, and a small build pipeline. The image explains that the repo removes surface area instead of adding more layers to manage. — The repo is not trying to be the most expansive starter. It is trying to be the shortest path from a source file to a package that behaves like a real dependency.

Dimension	preview-rpc	Heavier starter kits	Hand-rolled setup
Local preview	Vite aliases the package name back to live source in the kitchen-sink sandbox.	Often relies on separate demo apps or docs layers that sit beside the library.	Depends on whatever local preview script the author remembered to maintain.
Build outputs	One source tree can become ESM, CJS, and IIFE without a sprawling toolchain.	May include more infrastructure than the library itself needs.	Can drift into ad hoc scripts and inconsistent release artifacts.
Package hygiene	publint checks the export surface before release, so the package boundary stays readable.	Validation is often spread across more tools and more config files.	Quality checks are easy to skip when they are not standardized.
Maintenance burden	Small, opinionated, and easy to audit.	Higher, because every extra layer adds another place for drift.	Low at first, then expensive once the shortcuts start accumulating.
Best fit	Small TypeScript libraries and preview-sensitive utilities.	Teams that need docs, app scaffolding, and marketing surfaces in the same repo.	One-off experiments or teams that want complete freedom over every script.

That is the real tradeoff. preview-rpc does less, but the less is deliberate. The preview loop is trustworthy because it is treated like production, and the publish loop stays small because the repo refuses to be a general-purpose app shell.

Who should use preview-rpc, and who should not

Use it if you build TypeScript libraries, tiny SDKs, or preview-sensitive utilities.
Use it if you want one sandbox that feels like the package you are about to publish.
Skip it if your repo needs a full docs site, content platform, or design-system shell.
Skip it if your team wants a broad app starter more than a narrow library starter.

The broader RPC ecosystem still matters as a contrast. tRPC leans into application-scale type safety, gRPC-web brings heavier infrastructure into the browser, and JSON-RPC stays protocol-first. preview-rpc chooses a smaller problem, then makes that smaller problem feel finished.