pyRPCThere is a tension at the heart of v0.12.0. The release makes generated types a runtime module, which requires real configuration: a tsconfig paths alias, and for many bundlers a second alias in the bundler's own config. Yet pyRPC's promise is zero-config. How can a release that demands more configuration be a release toward less?
The two readings of "zero config"
There is config-you-write and config-the-tool-manages. pyRPC's promise is the former, not the latter. You should never have to write paths entries or alias lines by hand. The tool may absolutely maintain config (writing it into your files, idempotently, on every regeneration) as long as it does so invisibly and correctly.
// The developer never writes this:
"paths": { "@pyrpc/types": ["./__pyrpc.ts"] }
// or this:
turbopack: { resolveAlias: { "@pyrpc/types": "./__pyrpc.ts" } }
// pyrpc dev injects both, and keeps them correct.The cost of the runtime pivot
When types were compile-time only, one configuration surface (tsconfig paths) was enough, and even that was only needed because the adapter imported a type. The moment the adapter imports a value, every tool that resolves imports at runtime must know the alias. That multiplies the configuration surface: tsconfig for the compiler, and bundler aliases for Vite, SvelteKit, Turbopack.
Left to a human, that is a worse experience, more places to configure, more ways to get it subtly wrong. The release's answer is not to ask less of configuration; it is to take ownership of more of it.
How ownership is earned
Taking ownership of config files is only acceptable if the edits are trustworthy. v0.12.0's wiring layer was built to that standard:
- Surgical. A tokenizer finds the config object and splices one line; it never reformats your file.
- Idempotent. Re-runs converge; no-op regens leave files byte-identical.
- Non-destructive. A config it cannot safely edit is left alone with a warning, not mangled.
- Fail-closed. If the wiring never happened, the throwing placeholder makes the gap obvious.
Each of these properties is what turns "the tool edits my config" from a horror story into a non-event. Zero-config is not magic, it is automation that has earned trust.
The shifting line
As pyRPC's feature set grows, the line between "you configure" and "we configure" keeps moving. What used to require a tsconfig edit now requires nothing but running the dev server. The recurring lesson is the same: move configuration into the tool, then make the tool's edits provably safe. Safety mechanisms (idempotency, surgical edits, loud failures) are the price of admission for every configuration surface a tool takes over.
The paradox resolved
v0.12.0 introduced a second alias surface, and by doing so it moved the project closer to zero-config: the surface the developer must understand manually now sits behind a tool that manages it. Zero-config, honestly, means "config that maintains itself", and a runtime module is simply a sharper test of whether the automation actually does.