common

Unified protobuf code generation for Go, TypeScript, C++, and Rust with WASM.

What is this?

This repository provides the aptre CLI — a single tool that generates protobuf code for four languages without requiring you to install protoc, protoc plugins, or language-specific toolchains. Everything runs via embedded WebAssembly modules using wazero.

Key Features

• Zero native dependencies — protoc and plugins run as WASM, no installation required
• Multi-language output — generates Go, TypeScript, C++, and Rust from a single command
• Smart caching — only regenerates when source files actually change
• Go-style imports — use familiar import paths in your .proto files

Supported Languages

| Language | Message Types | RPC Services | Plugin | | ---------- | ------------- | ------------------- | -------------------------- | | Go | *.pb.go | *_srpc.pb.go | protobuf-go-lite | | TypeScript | *.pb.ts | *_srpc.pb.ts | protobuf-es-lite | | C++ | *.pb.cc/h | *_srpc.pb.hpp/cpp | Built-in protoc + starpc | | Rust | *.pb.rs | *_srpc.pb.rs | prost (WASI) + starpc |

Rust Support via WASI

The Rust code generation uses an embedded WASI build of protoc-gen-prost, meaning you don't need Cargo, rustc, or any Rust toolchain installed to generate .pb.rs files. The prost plugin runs entirely within the wazero WebAssembly runtime alongside protoc itself.

This is powered by go-protoc-gen-prost, which embeds a ~600KB WASM binary that implements the full prost protobuf code generator.

Example Output

Given a simple proto file:

syntax = "proto3";
package echo;

message EchoMsg {
  string body = 1;
}

The generated echo.pb.rs:

// @generated
// This file is @generated by prost-build.
#[derive(Clone, PartialEq, Eq, Hash, ::prost::Message)]
pub struct EchoMsg {
    #[prost(string, tag="1")]
    pub body: ::prost::alloc::string::String,
}

See starpc for a complete example.

Installation

# Run directly (no install needed)
go run github.com/aperturerobotics/common/cmd/aptre@latest generate

# Or install globally
go install github.com/aperturerobotics/common/cmd/aptre@latest

Quick Start

1. Set up your project with Go and optionally TypeScript:

# Initialize Go module
go mod init github.com/yourorg/yourproject

2. Create a proto file using Go-style imports:

syntax = "proto3";
package example;

// Import .proto files using Go-style import paths
import "github.com/aperturerobotics/controllerbus/controller/controller.proto";

message GetBusInfoResponse {
  repeated controller.Info running_controllers = 1;
}

3. Generate code:

# Stage files for git (required for discovery)
git add -A

# Generate all languages
go run github.com/aperturerobotics/common/cmd/aptre@latest generate

# Or with verbose output
go run github.com/aperturerobotics/common/cmd/aptre@latest generate --verbose

CLI Commands

| Command | Description | | ------------------ | -------------------------------------------------- | | generate | Generate protobuf code (Go, TypeScript, C++, Rust) | | generate --force | Regenerate all files, ignoring cache | | clean | Remove generated files and cache | | deps | Ensure all dependencies are installed | | lint | Run golangci-lint | | fix | Run golangci-lint with --fix | | test | Run go test | | test --browser | Run tests in browser with WebAssembly | | format | Format Go code with gofumpt | | outdated | Show outdated dependencies |

How It Works

The aptre tool orchestrates code generation using embedded WebAssembly:

1. Discovery — Finds .proto files matching your targets (default: ./*.proto)
2. Caching — Checks .protoc-manifest.json to skip unchanged files
3. Protoc (WASM) — Runs go-protoc-wasi to parse protos and invoke plugins
4. Plugins — Native plugins for Go/TS, WASM plugin for Rust (prost)
5. Post-processing — Fixes imports and formats output

Architecture

┌─────────────────────────────────────────────────────────────┐
│                         aptre CLI                           │
├─────────────────────────────────────────────────────────────┤
│                     wazero runtime                          │
├─────────────┬─────────────────────────┬─────────────────────┤
│ protoc.wasm │  protoc-gen-prost.wasm  │   Native Plugins    │
│  (parsing)  │     (Rust output)       │  (Go, TS, C++)      │
└─────────────┴─────────────────────────┴─────────────────────┘

C++ Support

C++ protobuf files (.pb.cc and .pb.h) are generated alongside other outputs. Add vendor/ to your include path:

# CMakeLists.txt
include_directories(${PROJECT_SOURCE_DIR}/vendor)

#include "github.com/yourorg/yourproject/example/example.pb.h"

For StarPC C++ services, the *_srpc.pb.hpp files provide client/server stubs.

Configuration

The generator uses sensible defaults but can be customized:

• Targets: Proto file patterns (default: ./*.proto)
• Exclude: Patterns to skip (e.g., vendor/**)
• ToolsDir: Plugin binary location (default: .tools)
• Cache: Manifest file (default: .protoc-manifest.json)

package.json Configuration

When a repo has a package.json, aptre generate also reads an optional top-level aptre config object from it.

Example:

{
  "name": "spacewave",
  "private": true,
  "aptre": {
    "tsImportBoundaries": ["auth", "bldr", "db", "forge", "identity", "net"]
  }
}

aptre.tsImportBoundaries

tsImportBoundaries configures how generated TypeScript protobuf imports are rewritten inside a monorepo.

By default, same-module generated imports stay relative. That is usually what you want in a single-package repo.

For monorepos that generate protobuf TypeScript into multiple top-level members, relative imports can break when a build system mirrors sources into another tree or when each member needs a stable repo-root import path. In that case, define module-relative boundary prefixes in aptre.tsImportBoundaries.

When a generated *.pb.ts file imports another generated protobuf file:

• If the import stays within the same configured boundary, it remains relative.
• If the import crosses from one configured boundary to another, aptre rewrites it to an @go/... import.
• Imports that resolve outside the current module are still rewritten to @go/... from vendor/ as before.

Given:

{
  "aptre": {
    "tsImportBoundaries": ["bldr", "db"]
  }
}

an import like:

import { VolumeInfo } from '../../db/volume/volume.pb.js'

in bldr/plugin/plugin.pb.ts becomes:

import { VolumeInfo } from '@go/github.com/yourorg/yourrepo/db/volume/volume.pb.js'

Boundary entries are matched against paths relative to the Go module root, so they should name repo directories such as bldr, db, or net, not full module paths.

Related Projects

• starpc — Streaming RPC for Go, TypeScript, and Rust
• protobuf-go-lite — Lightweight Go protobuf without reflection
• protobuf-es-lite — Lightweight TypeScript protobuf
• go-protoc-wasi — Embedded protoc as WASM
• go-protoc-gen-prost — Prost plugin as WASM
• template — Project template using this package
• protobuf-project — More extensive example

Support

Please open a GitHub issue with any questions or issues.

... or reach out on Matrix Chat or Discord.

License

MIT