protolint

protolint

protolint は、Protocol Buffer ファイル（proto2+proto3）用のプラグイン対応リンティング／修正ツールです。

• コンパイラーを使わないため、高速に実行できます。
• 公式スタイルガイドに簡単に準拠できます。ルールはスタイルガイドと完全に対応しています。
  • フィクサーが、公式スタイルガイドへの違反を可能な限り自動で修正します。
• Protocol Buffer ファイル内のコメントでルールを無効化できます。
  • API 互換性を保ちながら、可能な限りスタイルガイドを適用する必要があるプロジェクトに便利です。
  • 違反箇所にコメントを挿入すると、一部のルールを自動で無効化できます。
• プラグインを読み込み、カスタムの lint ルールを追加できます。
• すべてのルールについてテストを実施しています。
• 多くの連携機能に対応しています。
  • protoc プラグイン
  • エディター連携
  • GitHub Action
  • CI 連携

デモ

MCP サーバーを設定すると、Claude Desktop などの MCP クライアントに、次のように Protocol Buffer ファイルの lint と修正を依頼できます。

また、vim-protolint は次のように動作します。

MCP サーバー

protolint には Model Context Protocol (MCP) のサポートが含まれるようになり、AI モデルが protolint と直接やり取りできるようになりました。

使い方

protolint --mcp

protolint の MCP サーバー機能の使い方と統合方法の詳細については、MCP ドキュメントをご覧ください。

インストール

Homebrew を使用する

yoheimuta/protolint tap を通じて、Homebrew を使用して Mac または Linux に protolint をインストールできます。

brew tap yoheimuta/protolint
brew install protolint

homebrew-core に protolint, が含まれているため、brew install protolint. だけでインストールすることもできます。これはデフォルトでインストールされるデフォルトの tap です。こちらのほうが簡単ですが、同じ作者によってメンテナンスされているわけではありません。最新の状態を保つには、まず brew tap yoheimuta/protolint を実行することをおすすめします。

GitHub Releases を使用する

次のリリースページから、ビルド済みバイナリをダウンロードすることもできます。

• https://github.com/yoheimuta/protolint/releases

各リリースのダウンロードセクションには、.tar.gz パッケージに含まれるビルド済みバイナリがあります。

メンテナンスされている Docker イメージを使用する

protolint は Docker イメージ yoheimuta/protolint を提供しており、Docker のワークフローの一部として protolint を使用できます。

❯❯❯ docker run --volume "$(pwd):/workspace" --workdir /workspace yoheimuta/protolint lint _example/proto
[_example/proto/invalidFileName.proto:1:1] File name should be lower_snake_case.proto.
[_example/proto/issue_88/oneof_options.proto:11:5] Found an incorrect indentation style "    ". "  " is correct.
[_example/proto/issue_88/oneof_options.proto:12:5] Found an incorrect indentation style "    ". "  " is correct.

ソースからインストールする

Go が利用可能な場合、ソースからバイナリをインストールできます。 ただし、バージョン情報が含まれないため、ビルド済みバイナリのいずれかを使用することをおすすめします。

go install github.com/yoheimuta/protolint/cmd/protolint@latest

JavaScript／TypeScript 内

npm や yarn などの Node.js パッケージマネージャーを使って protolint を利用できます。

$ npm install protolint --save-dev

これにより、ローカルの package.json に開発依存関係への参照が追加されます。

インストール時に、postinstall.js スクリプトが呼び出されます。このスクリプトは、対応する protolint を github からダウンロードします。@electron/get と同様に、次の環境変数を使ってダウンロードを迂回できます。

環境変数	デフォルト値	説明
PROTOLINT_MIRROR_HOST	https://github.com	バイナリをホストする HTTP／Web サーバーのベース URL
PROTOLINT_MIRROR_REMOTE_PATH	yoheimuta/protolint/releases/download	リモートホスト上のアーカイブへのパス
PROTOLINT_MIRROR_USERNAME		HTTP Basic 認証のユーザー名
PROTOLINT_MIRROR_PASSWORD		HTTP Basic 認証のパスワード
PROTOLINT_PROXY		認証情報を指定できる HTTP(S) プロキシ

リモートパス内には、リリースページのアーカイブをミラーリングする必要があります。

その後、開発スクリプト内で npx protolint（指定したすべての protolint 引数とともに）を使用できます。

{
  ...
  "scripts": {
    "protoc": "....",
    "preprotoc": "npx protolint"
  },
  ...
}

package.json に protolint ノードを追加できます。このノードには、以下の protolint.yml の内容を lint ノードの下に記述できます。つまり、設定のルート要素は protolint になります。

TSC コンパイラーに一致する出力を得たい場合は、レポーターに tsc を指定してください。

Python プロジェクト内

Python プロジェクトでリンターとして protolint を利用できます。pypi の wheel protolint-bin には、さまざまなプラットフォーム向けにコンパイル済みのバイナリが含まれています。希望するバージョンを pyproject.toml または requirements.txt に追加してください。

ダウンロードされる wheel には、コンパイル済みの Go バイナリ protolint と protoc-gen-protolint が含まれます。お使いのプラットフォームは、サポート対象のバイナリプラットフォームと互換性がある必要があります。

pyproject.toml の tools.protolint パッケージにリンター設定を追加できます。

使い方

protolint lint example.proto example2.proto # file mode, specify multiple specific files
protolint lint .                            # directory mode, search for all .proto files recursively
protolint .                                 # same as "protolint lint ."
protolint lint -stdin_filename=v1/f.proto - # read from stdin and assume its path is v1/f.proto
protolint lint -config_path=path/to/your_protolint.yaml . # use path/to/your_protolint.yaml
protolint lint -config_dir_path=path/to .   # search path/to for .protolint.yaml
protolint lint -fix .                       # automatically fix some of the problems reported by some rules
protolint lint -fix -auto_disable=next .    # this is preferable when you want to fix problems while maintaining the compatibility. Automatically fix some problems and insert disable comments to the other problems. The available values are next and this.
protolint lint -auto_disable=next .         # automatically insert disable comments to the other problems. 
protolint lint -v .                         # with verbose output to investigate the parsing error
protolint lint -no-error-on-unmatched-pattern . # exits with success code even if no file is found (file & directory mode)
protolint lint -reporter junit .            # output results in JUnit XML format
protolint lint -output_file=path/to/out.txt # output results to path/to/out.txt
protolint lint -plugin ./my_custom_rule1 -plugin ./my_custom_rule2 .   # run custom lint rules.
protolint list                              # list all current lint rules being used
protolint version                           # print protolint version
protolint --version                         # print protolint version (global flag)
protolint -v                                # print protolint version (when used as the only argument)

protolint はデフォルトでは設定を必要とせず、ほとんどのプロジェクトですぐに使えます。

標準入力からの Lint

ファイルパスとして - を使用すると、標準入力から Protobuf の内容を Lint できます。 これは特に、スクリプトや IDE との統合に便利です。

cat example.proto | protolint lint -

設定の解決に仮想ファイル名を指定する場合や、よりわかりやすいエラー報告が必要な場合は、-stdin_filename フラグを使用してください。

cat example.proto | protolint lint -stdin_filename=api/v1/user.proto -

バージョン管理との統合

protolint は pre-commit フックとして利用できます。Go で protolint を実行するには、リポジトリの .pre-commit-config.yaml に次の設定を追加してください。

repos:
  - repo: https://github.com/yoheimuta/protolint
    rev: v0.56.3 # Select a release here
    hooks:
      - id: protolint

Docker ベースで実行する場合は、protolint-docker フックを使用してください。

repos:
  - repo: https://github.com/yoheimuta/protolint
    hooks:
      - id: protolint-docker # Uses yoheimuta/protolint:latest by default

重要： Docker フックでは、pre-commit の設計上、rev パラメーターはバージョン指定に使われません。特定の protolint バージョンに固定するには、entry に Docker イメージのタグを指定してください。

repos:
  - repo: https://github.com/yoheimuta/protolint
    hooks:
      - id: protolint-docker
        entry: yoheimuta/protolint:v0.55.6 lint # Pin to specific version

エディターとの統合

Visual Studio Code

• vscode-protolint
• protolint-vscode

JetBrains IntelliJ IDEA、GoLand、WebStorm、PHPStorm、PyCharm…

• intellij-protolint

Vim（ALE engine）

• aleの組み込みサポート

Vim（Syntastic）

• vim-protolint

GitHub Action

ワークフローでprotolintを実行するためのGitHub Action

• github/super-linter
• plexsystems/protolint-action
• yoheimuta/action-protolint - reviewdogと統合されています

CIとの統合

Jenkinsプラグイン

• warnings-ngおよびviolatons-libを使用するプラグイン

リンターアグリゲーター

• MegaLinterは、多数の組み込みリンターの一つとして、すぐにprotolintを実行します

環境固有の出力

CI/CD環境のフォーマットに合わせて、lintの出力を整形できます。出力フォーマットを使って環境を指定する必要があります。現在、次の出力形式に対応しています。

環境	コマンドライン値	説明	例
Github Actions	ci-gh	Githubヘルプ	::warning file=example.proto,line=10,col=20,title=ENUM_NAMES_UPPER_CAMEL_CASE::EnumField name \"SECOND.VALUE\" must be CAPITALS_WITH_UNDERSCORES
Azure DevOps	ci-az	Azure DevOpsヘルプ	##vso[task.logissue type=warning;sourcepath=example.proto;linenumber=10;columnnumber=20;code=ENUM_NAMES_UPPER_CAMEL_CASE;]EnumField name \"SECOND.VALUE\" must be CAPITALS_WITH_UNDERSCORES
Gitlab CI/CD	ci-glab	例からリバースエンジニアリング	WARNING: ENUM_NAMES_UPPER_CAMEL_CASE example.proto(10,20) : EnumField name \"SECOND.VALUE\" must be CAPITALS_WITH_UNDERSCORES

汎用的な問題マッチャーを作成する汎用フォーマッターciも使用できます。

ci-envの値を使うと、次の環境変数からテンプレートを指定できます。

環境変数	優先度	意味
PROTOLINT_CIREPORTER_TEMPLATE_STRING	1	Goテンプレートを含む文字列
PROTOLINT_CIREPORTER_TEMPLATE_FILE	2	Goテンプレートを含むファイルのパス

改行は自動的に追加されるため、出力行に改行を追加しないでください。

次のフィールドを使用できます。

Severity : 文字列で表した重要度（note、warning、errorのいずれか）

File : エラーを含むファイルのパス

Line : エラーを含むfile内の行（開始位置）

Column : エラーを含むfile内の列（開始位置）

Rule : 問題のあるルールの名前

Message : エラーの内容を説明するエラーメッセージ

出力ファイルとCI/CDエラーストリームの生成

CI/CD環境に合わせた出力を作成すると同時に、github CodeQLやSonarQubeなどの静的コード解析ツール向けに出力ファイルを作成できます。

--add-reporterフラグを追加すると実行できます。 値は<reporter-name>:<output-file-path>の形式で指定する必要があります（<と>は省略します）。

$ protolint --reporter ci-gh --add-reporter sarif:/path/to/my/output.sarif.json proto/*.proto

protoc プラグインとして使用する

protolint は、protoc プラグインとして lint 機能を実行するバイナリ protoc-gen-protolint も提供しています。 詳しくは、cmd/protoc-gen-protolint/README.md をご覧ください。

protoc プラグインを使ったワークフローがすでにある場合に便利です。

Go コードから呼び出す

Go コードから protolint を使用することもできます。 詳しくは、Go Documentation と lib/lint_test.go をご覧ください。

import (
    "bytes"

    "github.com/yoheimuta/protolint/lib"
)

func main() {
    args := []string{"-config_path", "path/to/your_protolint.yaml", "."}
    var stdout bytes.Buffer
    var stderr bytes.Buffer

    err := lib.Lint(args, &stdout, &stderr)
    if err != nil {
        // Handle error
    }

    // Process output in stdout and stderr
}

ルール

詳しくは internal/addon/rules をご覧ください。

ルールセットは次のとおりです。

• 公式スタイルガイド。デフォルトで有効です。基本的に、これらのルールによる違反は -fix オプションを追加すると修正できます。
• 非公式スタイルガイド。デフォルトで無効です。.protolint.yaml で各ルールを有効にできます。

コマンドラインの -fix オプションを使用すると、修正可能なルールによって報告された問題をすべて自動的に修正できます。 以下の Fixable 列をご覧ください。

コマンドラインの -auto_disable オプションを使用すると、自動無効化ルールによって報告された問題をすべて自動的に無効化できます。 既存の違反を修正すると互換性が損なわれる場合に、この機能が役立ちます。 以下の AutoDisable 列をご覧ください。

• *1: 修正によって互換性が損なわれないため、これらのルールは AutoDisable に対応する予定はありません。protolint を -fix オプション付きで実行してください。 | 公式 | 修正可能 | 自動無効化 | ID | 目的 | |----|----|---|-------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | はい | ✅ | ✅ | ENUM_FIELD_NAMES_PREFIX | enum のフィールド名に ENUM_NAME_UPPER_SNAKE_CASE のプレフィックスが付いていることを検証します。 | | はい | ✅ | ✅ | ENUM_FIELD_NAMES_UPPER_SNAKE_CASE | すべての enum フィールド名が大文字とアンダースコアで構成されていることを検証します。 | | はい | ✅ | ✅ | ENUM_FIELD_NAMES_ZERO_VALUE_END_WITH | ゼロ値の enum にサフィックス（例：「UNSPECIFIED」、「INVALID」）が付いていることを検証します。デフォルトは「UNSPECIFIED」です。.protolint.yaml でサフィックスを設定できます。 | | はい | ✅ | ✅ | ENUM_NAMES_UPPER_CAMEL_CASE | すべての enum 名がアッパーキャメルケース（先頭が大文字）であることを検証します。 | | はい | ✅ | *1 | FILE_NAMES_LOWER_SNAKE_CASE | すべてのファイル名が lower_snake_case.proto であることを検証します。.protolint.yaml で除外するファイルを設定できます。 | | はい | ✅ | ✅ | FIELD_NAMES_LOWER_SNAKE_CASE | すべてのフィールド名がアンダースコア区切りであることを検証します。 | | はい | ✅ | *1 | IMPORTS_SORTED | すべての import がソートされていることを検証します。 | | はい | ✅ | ✅ | MESSAGE_NAMES_UPPER_CAMEL_CASE | すべてのメッセージ名がアッパーキャメルケース（先頭が大文字）であることを検証します。 | | はい | ✅ | *1 | ORDER | すべてのファイルが指定された順序になっていることを検証します。 | | はい | ✅ | *1 | PACKAGE_NAME_LOWER_CASE | パッケージ名に小文字のみが含まれていることを検証します。 | | はい | ✅ | ✅ | RPC_NAMES_UPPER_CAMEL_CASE | すべての rpc 名がアッパーキャメルケース（先頭が大文字）であることを検証します。 | | はい | ✅ | ✅ | SERVICE_NAMES_UPPER_CAMEL_CASE | すべてのサービス名がアッパーキャメルケース（先頭が大文字）であることを検証します。 | | はい | ✅ | ✅ | REPEATED_FIELD_NAMES_PLURALIZED | repeated フィールド名が複数形であることを検証します。 | | はい | ✅ | *1 | QUOTE_CONSISTENT | 文字列に使用する引用符が統一されていることを検証します。デフォルトは二重引用符です。.protolint.yaml で引用符を設定できます。 | | はい | ✅ | *1 | INDENT | インデントスタイルを統一します。デフォルトのスタイルはスペース 2 個です。適切な改行もデフォルトで強制されます。.protolint.yaml で詳細を設定できます。 | | はい | ✅ | *1 | PROTO3_FIELDS_AVOID_REQUIRED | proto3 ではすべてのフィールドで required を避けることを検証します。 | | はい | _ | ✅ | PROTO3_GROUPS_AVOID | proto3 ではすべての group を避けることを検証します。 | | はい | _ | *1 | MAX_LINE_LENGTH | 行の最大長を制限します。行の長さは、その行に含まれる Unicode 文字数で定義されます。デフォルトは 80 文字です。.protolint.yaml で詳細を設定できます。 | | いいえ | _ | - | SERVICE_NAMES_END_WITH | サービス名のサフィックスを統一します。.protolint.yaml でサフィックスを設定できます。 | | いいえ | _ | - | FIELD_NAMES_EXCLUDE_PREPOSITIONS | すべてのフィールド名に前置詞（例：「for」、「during」、「at」）が含まれていないことを検証します。.protolint.yaml で前置詞と除外するキーワードを設定できます。 | | いいえ | _ | - | MESSAGE_NAMES_EXCLUDE_PREPOSITIONS | すべてのメッセージ名に前置詞（例：「With」、「For」）が含まれていないことを検証します。.protolint.yaml で前置詞と除外するキーワードを設定できます。 | | いいえ | _ | - | RPC_NAMES_CASE | すべての rpc 名が指定された規則に従っていることを検証します。.protolint.yaml で規則を設定する必要があります。 | | いいえ | _ | - | MESSAGES_HAVE_COMMENT | すべてのメッセージにコメントがあることを検証します。.protolint.yaml で Golang スタイルのコメントを強制するよう設定できます。 | | いいえ | _ | - | SERVICES_HAVE_COMMENT | すべてのサービスにコメントがあることを検証します。.protolint.yaml で Golang スタイルのコメントを強制するよう設定できます。 | | いいえ | _ | - | RPCS_HAVE_COMMENT | すべての rps にコメントがあることを検証します。.protolint.yaml で Golang スタイルのコメントを強制するよう設定できます。 | | いいえ | _ | - | FIELDS_HAVE_COMMENT | すべてのフィールドにコメントがあることを検証します。.protolint.yaml で Golang スタイルのコメントを強制するよう設定できます。 | | いいえ | _ | - | ENUMS_HAVE_COMMENT | すべての enum にコメントがあることを検証します。.protolint.yaml で Golang スタイルのコメントを強制するよう設定できます。 | | いいえ | _ | - | ENUM_FIELDS_HAVE_COMMENT | すべての enum フィールドにコメントがあることを検証します。.protolint.yaml で Golang スタイルのコメントを強制するよう設定できます。 | | いいえ | _ | - | FILE_HAS_COMMENT | ファイルがドキュメントコメントで始まっていることを検証します。 | | いいえ | _ | - | SYNTAX_CONSISTENT | 構文が指定されたバージョンであることを検証します。デフォルトは proto3 です。.protolint.yaml でバージョンを設定できます。 | | いいえ | _ | - | FIELD_NUMBERS_ORDER_ASCENDING | フィールド番号が昇順であることを検証します。enum では option allow_alias = true; を考慮し、隣接する同じ番号（非減少）を許可します。 | .protolint.yaml に all_default: true を追加することをおすすめします。上記のすべてのリンターが自動的に有効になるため、protolint が更新されるたびに、そのメリットを最大限に活用できます。

デフォルトで有効になっている、適切なスタイルの例をいくつか紹介します。 - は悪いスタイル、+ は良いスタイルです。

ENUM_FIELD_NAMES_PREFIX

enum FooBar {
-  UNSPECIFIED = 0;
+  FOO_BAR_UNSPECIFIED = 0;
}

ENUM_FIELD_NAMES_UPPER_SNAKE_CASE

enum Foo {
-  firstValue = 0;
+  FIRST_VALUE = 0;
-  second_value = 1;
+  SECOND_VALUE = 1;
}

ENUM_FIELD_NAMES_ZERO_VALUE_END_WITH

enum Foo {
-  FOO_FIRST = 0;
+  FOO_UNSPECIFIED = 0;
}

ENUM_NAMES_UPPER_CAMEL_CASE

- enum foobar {
+ enum FooBar {
  FIRST_VALUE = 0;
  SECOND_VALUE = 1;
}

FIELD_NAMES_LOWER_SNAKE_CASE

message SongServerRequest {
-  required string SongName = 1;
+  required string song_name = 1;
}

IMPORTS_SORTED

- import public "new.proto";
+ import "myproject/other_protos.proto";
- import "myproject/other_protos.proto";
+ import public "new.proto";

import "google/protobuf/empty.proto";
import "google/protobuf/timestamp.proto";

MESSAGE_NAMES_UPPER_CAMEL_CASE

- message song_server_request {
+ message SongServerRequest {
  required string SongName = 1;
  required string song_name = 1;
}

ORDER

- option java_package = "com.example.foo";
- syntax = "proto3";
- package examplePb;
- message song_server_request { }
- import "other.proto";
+ syntax = "proto3";
+ package examplePb;
+ import "other.proto";
+ option java_package = "com.example.foo";
+ message song_server_request { }

PACKAGE_NAME_LOWER_CASE

- package myPackage
+ package my.package

RPC_NAMES_UPPER_CAMEL_CASE

service FooService {
-  rpc get_something(FooRequest) returns (FooResponse);
+  rpc GetSomething(FooRequest) returns (FooResponse);
}

RPC_NAMES_UPPER_CAMEL_CASE

- service foo_service {
+ service FooService {
  rpc get_something(FooRequest) returns (FooResponse);
  rpc GetSomething(FooRequest) returns (FooResponse);
}

REPEATED_FIELD_NAMES_PLURALIZED

-  repeated string song_name = 1;
+  repeated string song_names = 1;

INDENT

 enum enumAllowingAlias {
   UNKNOWN = 0;
-        option allow_alias = true;
+  option allow_alias = true;
   STARTED = 1;
-     RUNNING = 2 [(custom_option) = "hello world"];
+  RUNNING = 2 [(custom_option) = "hello world"];
- }
+}

-   message TestMessage { string test_field = 1; }
+ message TestMessage {
+  string test_field = 1;
+}

QUOTE_CONSISTENT

 option java_package = "com.example.foo";
- option go_package = 'example';
+ option go_package = "example";

独自ルールの作成

protolint はプラグイン対応のリンターなので、独自の lint ルールを自由に作成できます。

完全なサンプルプロジェクト（プラグイン）は、このリポジトリの _example/plugin ディレクトリに含まれています。

レポーター

protolint には、lint 結果の表示形式を制御する複数の組み込みレポーター（フォーマッター）が用意されています。

コマンドラインで -reporter フラグを指定すると、レポーターを選択できます。たとえば、-reporter junit を指定すると、junit レポーターが使用されます。

組み込みレポーターのオプションは次のとおりです。

• plain（デフォルト）
• junit
• json
• sarif
• sonar（SonarQube 汎用イシューフォーマット）
• unix
• tsc（TypeScript コンパイラーと互換性があります）

設定

Protocol Buffer ファイルでのルールの無効化

Protocol Buffer ファイル内のコメントで、次の形式を使用してルールを無効にできます。 ルールは、ファイルの末尾に達するか、対応する有効化コメントをリンターが検出するまで無効になります。

// protolint:disable <ruleID1> [<ruleID2> <ruleID3>...]
...
// protolint:enable <ruleID1> [<ruleID2> <ruleID3>...]

無効化コマンドに :next または :this を追加すると、コマンドの適用対象を、それぞれ次の行または現在の行のみに変更できます。

例：

enum Foo {
  // protolint:disable:next ENUM_FIELD_NAMES_UPPER_SNAKE_CASE
  firstValue = 0;    // no error
  second_value = 1;  // protolint:disable:this ENUM_FIELD_NAMES_UPPER_SNAKE_CASE
  THIRD_VALUE = 2;   // spits out an error
}

コマンドラインオプション -auto_disable に next または this を設定すると、問題が検出されたときに無効化コマンドが挿入されます。

-fix オプションも併せて指定できます。auto_disable をサポートするルールは、スキーマとの互換性を損なう修正を行う代わりに、違反を抑制します。

設定ファイル

protolint は .protolint.yaml という名前の設定ファイルを使用して動作できます。

設定ファイルの仕様については、_example/config/.protolint.yaml を参照してください。

デフォルトでは、protolint は現在の作業ディレクトリから設定ファイルを自動的に検索し、続いてファイルシステムのルートディレクトリまで親ディレクトリを順に検索します。 -config_dir_path フラグを使用すると、指定したディレクトリを検索できます。 --config_path フラグを使用すると、指定したファイルを検索できます。

終了コード

ファイルの lint 時に、protolint は次のいずれかの終了コードで終了します。

• 0：Lint に成功し、lint エラーはありません。
• 1：Lint に成功しましたが、少なくとも 1 つの lint エラーがあります。
• 2：解析エラー、内部エラー、実行時エラーなど、その他のエラーにより lint に失敗しました。

開発の動機

2018/12/20 時点で、類似の protobuf リンターが存在します。

1 つは、Google の Protocol Buffers コンパイラー用プラグインです。

• ファイルの lint だけを行いたい場合、コンパイル環境を構築するのは面倒なことがあります。
• また一般に、ファイルの解析よりもコンパイルに多くの時間がかかります。

もう 1 つは、Protocol Buffer ファイルを lint するコマンドラインツールです。

• lint 以外の機能も数多く備えているため、リンターだけを使いたいユーザーにとっては扱いづらいようです。
• lint ルールは、独自の考え方に偏っている傾向があります。
• さらに、ルールセットと公式のスタイルガイドは完全には対応していません。ルールとガイドの両方を詳細に理解し、ルールを正確に組み合わせる必要があります。

その他のツール

2019/12/17に、protolintを含むさまざまなProtocol Bufferリンターを比較する記事を書きました。

• https://qiita.com/yoheimuta/items/da7678fcd046b93a2637
  • 注：こちらの記事は日本語で書かれています。

依存関係

• go-protoparser

開発

リリース

リリースプロセスを効率化し、人的ミスを減らすため、リポジトリにはrelease.shスクリプトが含まれています。このスクリプトは、新しいリリースタグの作成とプッシュに必要な手順を自動化します。

使用方法

次のコマンドを実行して、新しいリリースを作成します。

bash release.sh <version> [message]

タグのプッシュは最初の手順にすぎません。CIがそのタグをもとにGitHub Releases、npm、PyPI、Maven Central、Docker Hub、Homebrewに公開します。各チャネルでの確認方法については、CONTRIBUTING.mdを参照してください。

ライセンス

MIT License（MIT）