Convert Figma logo to code with AI

pseudomuto logoprotoc-gen-doc

Documentation generator plugin for Google Protocol Buffers

2,638
464
2,638
120

Top Related Projects

gRPC to JSON proxy generator following the gRPC HTTP spec

Clean, modern, Python 3.6+ code generator & library for Protobuf 3 and async gRPC

4,254

Evans: more expressive universal gRPC client

8,992

The best way of working with Protocol Buffers.

Quick Overview

protoc-gen-doc is a documentation generator plugin for the Protocol Buffers compiler (protoc). It generates documentation from Protocol Buffer files in various formats, including HTML, Markdown, and JSON. This tool simplifies the process of creating and maintaining documentation for Protocol Buffer-based APIs.

Pros

  • Supports multiple output formats (HTML, Markdown, JSON)
  • Customizable templates for generating documentation
  • Integrates seamlessly with the Protocol Buffers compiler
  • Supports both proto2 and proto3 syntax

Cons

  • Limited styling options for HTML output
  • Requires manual integration into build processes
  • Documentation may become outdated if not regularly updated with proto file changes
  • Limited support for complex nested structures in some output formats

Code Examples

  1. Generate HTML documentation:
protoc --doc_out=./docs --doc_opt=html,index.html proto/*.proto

This command generates HTML documentation for all .proto files in the proto directory and saves it as index.html in the docs folder.

  1. Generate Markdown documentation:
protoc --doc_out=./docs --doc_opt=markdown,api.md proto/*.proto

This command generates Markdown documentation for all .proto files in the proto directory and saves it as api.md in the docs folder.

  1. Generate JSON documentation:
protoc --doc_out=./docs --doc_opt=json,api.json proto/*.proto

This command generates JSON documentation for all .proto files in the proto directory and saves it as api.json in the docs folder.

Getting Started

  1. Install protoc-gen-doc:
go install github.com/pseudomuto/protoc-gen-doc/cmd/protoc-gen-doc@latest
  1. Generate documentation:
protoc --doc_out=./docs --doc_opt=html,index.html path/to/your/*.proto

Replace html,index.html with your desired output format and filename. Adjust the path to your .proto files as needed.

Competitor Comparisons

gRPC to JSON proxy generator following the gRPC HTTP spec

Pros of grpc-gateway

  • Provides a RESTful API gateway for gRPC services, allowing easy integration with existing REST ecosystems
  • Supports automatic OpenAPI (Swagger) documentation generation
  • Offers bidirectional streaming and server-side streaming capabilities

Cons of grpc-gateway

  • More complex setup and configuration compared to protoc-gen-doc
  • Requires additional runtime dependencies and infrastructure
  • May introduce performance overhead due to protocol translation

Code Comparison

grpc-gateway:

service YourService {
  rpc CreateUser(CreateUserRequest) returns (User) {
    option (google.api.http) = {
      post: "/v1/users"
      body: "*"
    };
  }
}

protoc-gen-doc:

service YourService {
  // CreateUser creates a new user
  rpc CreateUser(CreateUserRequest) returns (User);
}

grpc-gateway focuses on generating a RESTful API gateway and OpenAPI documentation, while protoc-gen-doc is primarily designed for generating documentation from Protocol Buffer files. grpc-gateway requires additional annotations and configuration but offers more functionality in terms of API exposure and integration. protoc-gen-doc provides a simpler approach to documentation generation without the added complexity of API gateway features.

Clean, modern, Python 3.6+ code generator & library for Protobuf 3 and async gRPC

Pros of python-betterproto

  • Generates Python-specific code with type hints and dataclasses
  • Offers runtime performance improvements over standard protobuf libraries
  • Provides a more Pythonic API for working with protobuf messages

Cons of python-betterproto

  • Limited to Python language, unlike protoc-gen-doc's language-agnostic documentation
  • May require additional setup and integration compared to protoc-gen-doc's simpler documentation generation
  • Less focused on documentation generation, which is the primary purpose of protoc-gen-doc

Code Comparison

protoc-gen-doc (documentation generation):

{{range .Files}}
{{range .Messages}}
## {{.LongName}}
{{.Description}}
{{end}}
{{end}}

python-betterproto (Python code generation):

@dataclass
class ExampleMessage(betterproto.Message):
    field1: str = betterproto.string_field(1)
    field2: int = betterproto.int32_field(2)

The code snippets demonstrate the different focus areas of these projects. protoc-gen-doc generates documentation templates, while python-betterproto produces Python code with type hints and dataclasses for working with protobuf messages.

4,254

Evans: more expressive universal gRPC client

Pros of Evans

  • Interactive CLI tool for real-time gRPC communication and testing
  • Supports both unary and streaming RPCs
  • Offers a REPL environment for exploring gRPC services

Cons of Evans

  • Limited to gRPC interaction and doesn't generate documentation
  • Requires manual input for each request, which can be time-consuming for complex APIs
  • Less suitable for generating comprehensive API documentation

Code Comparison

Evans (REPL interaction):

> call SayHello
name (TYPE_STRING) => Alice
message (package.HelloReply) => {
  "message": "Hello, Alice!"
}

protoc-gen-doc (generated documentation):

<h2>SayHello</h2>
<p>Sends a greeting</p>
<h3>Request</h3>
<table>
  <tr><th>Field</th><th>Type</th><th>Description</th></tr>
  <tr><td>name</td><td>string</td><td>The name to greet</td></tr>
</table>

Summary

Evans is an interactive gRPC client tool, while protoc-gen-doc is a documentation generator for Protocol Buffers. Evans excels in real-time API testing and exploration, whereas protoc-gen-doc is better suited for creating comprehensive API documentation. The choice between them depends on whether you need interactive testing capabilities or static documentation generation for your gRPC services.

8,992

The best way of working with Protocol Buffers.

Pros of buf

  • Comprehensive toolchain for Protocol Buffers, including linting, breaking change detection, and code generation
  • Supports remote caching and distributed builds, improving performance for large projects
  • Offers a modern CLI interface with intuitive commands and extensive documentation

Cons of buf

  • Steeper learning curve due to its broader feature set
  • May be overkill for simple projects that only need documentation generation
  • Requires additional setup and configuration compared to simpler tools

Code comparison

protoc-gen-doc:

protoc --doc_out=./docs --doc_opt=markdown,docs.md myproto.proto

buf:

buf generate

Additional notes

protoc-gen-doc focuses specifically on documentation generation for Protocol Buffers, while buf is a more comprehensive toolchain. protoc-gen-doc is simpler to use for basic documentation needs, but buf offers more features and scalability for larger projects. buf's code generation is typically configured in a buf.gen.yaml file, allowing for more flexible and powerful generation options.

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

protoc-gen-doc

CI Status codecov GoDoc Go Report Card

This is a documentation generator plugin for the Google Protocol Buffers compiler (protoc). The plugin can generate HTML, JSON, DocBook, and Markdown documentation from comments in your .proto files.

It supports proto2 and proto3, and can handle having both in the same context (see examples for proof).

Installation

There is a Docker image available (docker pull pseudomuto/protoc-gen-doc) that has everything you need to generate documentation from your protos.

If you'd like to install this locally, you can go get it.

go install github.com/pseudomuto/protoc-gen-doc/cmd/protoc-gen-doc@latest

Alternatively, you can download a pre-built release for your platform from the releases page.

Finally, this plugin is also available on Maven Central. For details about how to use it, check out the gradle example.

Invoking the Plugin

The plugin is invoked by passing the --doc_out, and --doc_opt options to the protoc compiler. The option has the following format:

--doc_opt=<FORMAT>|<TEMPLATE_FILENAME>,<OUT_FILENAME>[,default|source_relative]

The format may be one of the built-in ones ( docbook, html, markdown or json) or the name of a file containing a custom Go template.

If the source_relative flag is specified, the output file is written in the same relative directory as the input file.

Using the Docker Image (Recommended)

The docker image has two volumes: /out and /protos which are the directory to write the documentation to and the directory containing your proto files.

You could generate HTML docs for the examples by running the following:

docker run --rm \
  -v $(pwd)/examples/doc:/out \
  -v $(pwd)/examples/proto:/protos \
  pseudomuto/protoc-gen-doc

By default HTML documentation is generated in /out/index.html for all .proto files in the /protos volume. This can be changed by passing the --doc_opt parameter to the container.

For example, to generate Markdown for all the examples:

docker run --rm \
  -v $(pwd)/examples/doc:/out \
  -v $(pwd)/examples/proto:/protos \
  pseudomuto/protoc-gen-doc --doc_opt=markdown,docs.md

You can also generate documentation for a single file. This can be done by passing the file(s) to the command:

docker run --rm \
  -v $(pwd)/examples/doc:/out \
  -v $(pwd)/examples/proto:/protos \
  pseudomuto/protoc-gen-doc --doc_opt=markdown,docs.md Booking.proto [OPTIONALLY LIST MORE FILES]

You can also exclude proto files that match specific path expressions. This is done by passing a second option delimited by :. For example, you can pass any number of comma separated patterns as the second option:

docker run --rm \
  -v $(pwd)/examples/doc:/out \
  -v $(pwd)/examples/proto:/protos \
  pseudomuto/protoc-gen-doc --doc_opt=:google/*,somepath/*

Remember: Paths should be from within the container, not the host!

NOTE: Due to the way wildcard expansion works with docker you cannot use a wildcard path (e.g. protos/*.proto) in the file list. To get around this, if no files are passed, the container will generate docs for protos/*.proto, which can be changed by mounting different volumes.

Simple Usage

For example, to generate HTML documentation for all .proto files in the proto directory into doc/index.html, type:

protoc --doc_out=./doc --doc_opt=html,index.html proto/*.proto

The plugin executable must be in PATH for this to work.

Using a precompiled binary

Alternatively, you can specify a pre-built/not in PATH binary using the --plugin option.

protoc \
  --plugin=protoc-gen-doc=./protoc-gen-doc \
  --doc_out=./doc \
  --doc_opt=html,index.html \
  proto/*.proto

With a Custom Template

If you'd like to use your own template, simply use the path to the template file rather than the type.

protoc --doc_out=./doc --doc_opt=/path/to/template.tmpl,index.txt proto/*.proto

For information about the available template arguments and functions, see Custom Templates. If you just want to customize the look of the HTML output, put your CSS in stylesheet.css next to the output file and it will be picked up.

Writing Documentation

Messages, Fields, Services (and their methods), Enums (and their values), Extensions, and Files can be documented. Generally speaking, comments come in 2 forms: leading and trailing.

Leading comments

Leading comments can be used everywhere.

/**
 * This is a leading comment for a message
 */
message SomeMessage {
  // this is another leading comment
  string value = 1;
}

NOTE: File level comments should be leading comments on the syntax directive.

Trailing comments

Fields, Service Methods, Enum Values and Extensions support trailing comments.

enum MyEnum {
  DEFAULT = 0; // the default value
  OTHER   = 1; // the other value
}

Excluding comments

If you want to have some comment in your proto files, but don't want them to be part of the docs, you can simply prefix the comment with @exclude.

Example: include only the comment for the id field

/**
 * @exclude
 * This comment won't be rendered
 */
message ExcludedMessage {
  string id   = 1; // the id of this message.
  string name = 2; // @exclude the name of this message

  /* @exclude the value of this message. */
  int32 value = 3;
}

Check out the example protos to see all the options.

Output Example

With the input .proto files

the plugin gives the output

Check out the examples task in the Makefile to see how these were generated.