https://www.quora.com/What-does-the-pl-command-do-in-OS-X-terminal-And-how-can-I-figure-this-out-without-asking-someone

Environment

• MacOS catalina

• Protolint Version 0.28.2

When I run protolint lint . I get a very weird error

found "\"package\"(Token=30, Pos=node_modules/grpc/node_modules/protobufjs/examples/protoify/json.proto:2:1)" but expected [syntax] at /go/pkg/mod/github.com/yoheimuta/go-protoparser/[email protected]/parser/syntax.go:59. Use -v for more details

Please I have been having this issues for some days now, I have tried ignoring the node_modules folder entirely in my protolint.yml config file but to no success.

Please help!

PS

This is the content of my protolint.yml file

lint:
  files:
    exclude:
      - node_modules/grpc/node_modules/protobufjs/examples/protoify/json.proto
  directories:
    # The specific directories to exclude.
    exclude:
      # NOTE: UNIX paths will be properly accepted by both UNIX and Windows.
      # - identity-service-proto/node_modules/
      - node_modules/
  rules:
    no_default: false # we can choose if we want the default linting in addition to our custom lintings too
    all_default: false

    add:
      # - MESSAGE_NAMES_UPPER_CAMEL_CASE
      # - SERVICE_NAMES_UPPER_CAMEL_CASE
      # - MESSAGES_HAVE_COMMENT
      # - REPEATED_FIELD_NAMES_PLURALIZED
      # - SERVICES_HAVE_COMMENT
      # - ENUM_FIELD_NAMES_UPPER_SNAKE_CASE
      # - ENUM_NAMES_UPPER_CAMEL_CASE
      # - FIELD_NAMES_LOWER_SNAKE_CASE
      # - PACKAGE_NAME_LOWER_CASE
      # - RPC_NAMES_UPPER_CAMEL_CASE

    remove:
      - MAX_LINE_LENGTH
      - MESSAGES_HAVE_COMMENT

Maybe related to fixing #66 I encountered a false-positive of the indent rule in the newest version 0.16.0 which is reported if the last rpc method of a service is having a statement block:

service SearchService {
  rpc Search (SearchRequest) returns (SearchResponse) {}
} // -> Found an incorrect indentation style "". "  " is correct.

In my case the rpc statement block is containing an option, but it's not needed to get the issue.

I have a following proto file:

syntax = "proto3";
// A broken example of the official reference
// See https://developers.google.com/protocol-buffers/docs/reference/proto3-spec#proto_file
package examplePb;

option java_package = "com.example.foo";

import "other.proto";
import public "new.proto";

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

import "myproject/other_protos.proto";
import "myproject/main_protos.proto";

enum enumAllowingAlias {
  option allow_alias = true;
  UNKNOWN = 0;
  STARTED = 1;
  RUNNING = 2 [(custom_option) = "hello world"];
}
message outer {
  option (my_option).a = true;
  // inner is an inner message.
  message innerAAA {   // Level 2
    int64 ival = 1;
  }
  repeated inner inner_message = 2;
  EnumAllowingAlias enum_field =3;
  map<int32, string> my_map = 4;
  string reason_for_error = 5;
  string  end_of_support_version= 6;
  message AccountForAdmin {}
  message SpecialEndOfSupport {}
  required inner inner_message = 7;
  group Result = 8 {
    string url = 9;
  }
  repeated group Result = 10 {
  }
  repeated inner paper = 11;
  repeated group Regular = 12 {
  }
}
service SearchApi {
  rpc search (SearchRequest) returns (SearchResponse) {};
};

So I create a custom linter rule custumrule/enumrule.go:

package custumrule

import (
	"github.com/yoheimuta/go-protoparser/v4/parser"
	"github.com/yoheimuta/protolint/linter/report"
	"github.com/yoheimuta/protolint/linter/strs"
	"github.com/yoheimuta/protolint/linter/visitor"
)

// EnumNamesLowerSnakeCaseRule verifies that all enum names are LowerSnakeCase.
type EnumNamesLowerSnakeCaseRule struct{}

// NewEnumNamesLowerSnakeCaseRule creates a new EnumNamesLowerSnakeCaseRule.
func NewEnumNamesLowerSnakeCaseRule() EnumNamesLowerSnakeCaseRule {
	return EnumNamesLowerSnakeCaseRule{}
}

// ID returns the ID of this rule.
func (r EnumNamesLowerSnakeCaseRule) ID() string {
	return "ENUM_NAMES_LOWER_SNAKE_CASE"
}

// Purpose returns the purpose of this rule.
func (r EnumNamesLowerSnakeCaseRule) Purpose() string {
	return "Verifies that all enum names are LowerSnakeCase."
}

// IsOfficial decides whether or not this rule belongs to the official guide.
func (r EnumNamesLowerSnakeCaseRule) IsOfficial() bool {
	return true
}

// Apply applies the rule to the proto.
func (r EnumNamesLowerSnakeCaseRule) Apply(proto *parser.Proto) ([]report.Failure, error) {
	v := &enumNamesLowerSnakeCaseVisitor{
		BaseAddVisitor: visitor.NewBaseAddVisitor(r.ID()),
	}
	return visitor.RunVisitor(v, proto, r.ID())
}

type enumNamesLowerSnakeCaseVisitor struct {
	*visitor.BaseAddVisitor
}

// VisitEnum checks the enum field.
func (v *enumNamesLowerSnakeCaseVisitor) VisitEnum(e *parser.Enum) bool {
	if !strs.IsLowerSnakeCase(e.EnumName) {
		v.AddFailuref(e.Meta.Pos, "Enum name %q must be underscore_separated_names", e.EnumName)
	}
	return false
}

and main.go:

package main

import (
	"example.com/m/custumrule"
	"github.com/yoheimuta/protolint/plugin"
)

func main() {
	plugin.RegisterCustomRules(
		custumrule.NewEnumNamesLowerSnakeCaseRule(),
	)
}

I build project on windows and Linux subsystem by go buil main.go and try to run the command: protolint -plugin ./main.exe .. However, I receive failed client.Client(), err=exec: "sh": executable file not found in %PATH%

Found this while running protolint on https://github.com/googleapis/googleapis/blob/master/google/api/annotations.proto

protolint -v ./annotations.proto results:

...
2019/06/12 14:13:29 [DEBUG] Text=[;], Token=[8], Pos=[proto/googleapis/google/api/annotations.proto:26:34] called from option.go:80                                                                      
2019/06/12 14:13:29 [DEBUG] Text=[extend], Token=[2], Pos=[proto/googleapis/google/api/annotations.proto:28:1] called from lexer.go:127                                                                  
2019/06/12 14:13:29 [DEBUG] Text=[extend], Token=[2], Pos=[proto/googleapis/google/api/annotations.proto:28:1] called from lexer.go:127                                                                  
2019/06/12 14:13:29 [DEBUG] Text=[extend], Token=[2], Pos=[proto/googleapis/google/api/annotations.proto:28:1] called from parser.go:44                                                                  
2019/06/12 14:13:29 [DEBUG] Text=[extend], Token=[2], Pos=[proto/googleapis/google/api/annotations.proto:28:1] called from lexer.go:127                                                                  
2019/06/12 14:13:29 [DEBUG] Text=[extend], Token=[2], Pos=[proto/googleapis/google/api/annotations.proto:28:1] called from emptyStatement.go:10                                                          
found "extend" but expected [;] at /Users/alexander/go/src/github.com/yoheimuta/go-protoparser/internal/lexer/emptyStatement.go:16  

I think extend keyword is missing but could not find it in proto styleguide.

For example, I want to introduce a new custom rule and then in the protolint.yaml file's rules_option section introduce new options for that particular custom rule?

I´m trying to use the disable marker on some proto files but i cannot get it to work on ENUMS rules.
For example, this file:

syntax = "proto3";
// protolint:disable ENUM_FIELD_NAMES_ZERO_VALUE_END_WITH
// protolint:disable ENUM_FIELD_NAMES_UPPER_SNAKE_CASE

package test;

import "google/protobuf/wrappers.proto";

option java_package = "com.test.example";
option java_outer_classname = "InfoProto";

/**
 * Some enum
*/
enum Strategy {
  DEFAULT= 0;
  bY_LINE_ID = 1;
  NONE = 2;
}

will always output these errors:

➜  ~ protolint lint example.proto
[example.proto:17:3] EnumField name "bY_LINE_ID" must be CAPITALS_WITH_UNDERSCORES
[example.proto:16:3] EnumField name "DEFAULT" with zero value should have the suffix "UNSPECIFIED"

I´ve tried with just one disable and I get the same result. I´ve found that other rules do work (e.g. protolint:enable MAX_LINE_LENGTH)

I am getting a warning from protoc but not from the linter (using the vscode extension).

For example:

warning: Import google/protobuf/wrappers.proto but not used.

I added the following to my proto file on the line before an 81 character long line (not really any good way to shorten the go_package option when you want to specify the full go package path).

// protolint:disable MAX_LINE_LENGTH

And yet I still get a linter error for the next line down:

[test.proto:8:1] The line length is 81, but it must be shorter than 80

Does protolint:disable not work with MAX_LINE_LENGTH? Or have I mucked up the syntax?

asis

• IMPORTS_SORTED
• INDENT

tobe

• More

The following proto raises errors around the "additional_bindings" line, even though this is a valid proto (another example here).

syntax = "proto3";

package test;

message Test {
}

service RunnerService {
    rpc StreamTest (Test) returns (stream Test) {
        option (google.api.http) = {
            get: "/v1/messages/{message_id}"
            additional_bindings {
                get: "/v1/users/{user_id}/messages/{message_id}"
            }
        };
    }
}

I have also seen the following syntax be used instead, but this also raises an error. However, this one seems to be thrown in the Lexer, rather than the Parser (as determined from the error message constants).

            additional_bindings: {
                get: "/v1/users/{user_id}/messages/{message_id}"
            };

PS: Sorry for the large amount of PRs/Issues raised 😅

ref. DEBUG log entries from plugin contained in JUnitReporter output · Issue #81 · yoheimuta/protolint

asis

• The report and logs output to stderr

tobe

• The report outputs to the specified file.
• Logs output to stderr as before.

Hi,
I'm currently trying to use this on gitlab ci, and currently don't have any files to lint, but I think since the linter exits with non zero the job fails.
isn't it better to exit with 0 when there's nothing to lint ?
here is what I use on gitlab:

protobuf-lint:
  image: 
    name: yoheimuta/protolint:v0.25.1
    entrypoint: [""]
  stage: test
  script:
    - protolint lint -v -reporter junit -output_file=junit.xml .
  artifacts:
    reports:
      junit: junit.xml
    expire_in: 1 week

I think it would be beneficial to also generate a Windows binary when creating releases

It would be great if a rule exists that prevents that the generated code for a specific programming language is invalid because of the use of reserved names for fields.

I had a field named "default" which produces errors when generating code for c/c++

Certain protos contain simple option assignments at the top of the file, before the imports. Linting these results in the following lint violation:
The order of Import is invalid. Check if the file is ordered in the correct manner.

These are usually used for language-specific generated code (java, python, go, csharp), to help specify optional importpaths.

My opinion is that there should be a toggle available to edit the ORDER setting, which allows simple option assignments to be placed before imports. This could be done in the following ways:

• Through a global setting, where all simple top-level option assignments are placed before the import when using the --fix mode.
• Through a whitelist system, where users can specify the specific option names to be placed at the top of the file.

Issue:

protolint reports an invalid indentation error, which breaks protos when using the --fix flag.

Expected outcome:

Valid proto output, as well as a correct error. This is not an indentation error, but a formatting error. The linter should be recommending the removal of the ; after the enum close.

Versions:

OS: macOS Mojave 10.14.6
protolint: 0.20.0 and 0.21.0

Steps to reproduce:

protolint lint test.proto where test.proto is:

syntax = "proto3";

package test;

message Test {
  enum State {
    UNKNOWN_STATE = 0;
    CLEAR = 1;
    PULLED = 2;
    STARTED = 3;
  };
}

message TestResponse {
}

service RunnerService {
  rpc ReceiveTest (Test) returns (TestResponse);
}

Protolint reports [test.proto:11:4] Found an incorrect indentation style " }". " " is correct., which breaks proto syntax.

I am running protolint version 0.26.1(84c57fd) running on macOS 11.0.1, and it's making this wrong transformation:

Looks like it's making a wrong transformation. To reporoduce the issue, save the below text into a .proto file:

syntax = "proto3";

package foobar;

option java_package = "com.test.foo.bar";

message TestMessage { string test_field = 1; }

Run:

protolint lint -v -fix test.proto

It prints the below output to console:

2020/12/04 21:05:04 [DEBUG] Text=[syntax], Token=[2], Pos=[test.proto:1:1] called from lexer.go:139
2020/12/04 21:05:04 [DEBUG] Text=[syntax], Token=[22], Pos=[test.proto:1:1] called from lexer.go:139
2020/12/04 21:05:04 [DEBUG] Text=[=], Token=[10], Pos=[test.proto:1:8] called from syntax.go:63
2020/12/04 21:05:04 [DEBUG] Text=["], Token=[11], Pos=[test.proto:1:10] called from syntax.go:68
2020/12/04 21:05:04 [DEBUG] Text=[proto3], Token=[2], Pos=[test.proto:1:11] called from syntax.go:73
2020/12/04 21:05:04 [DEBUG] Text=["], Token=[11], Pos=[test.proto:1:17] called from syntax.go:79
2020/12/04 21:05:04 [DEBUG] Text=[;], Token=[8], Pos=[test.proto:1:18] called from syntax.go:84
2020/12/04 21:05:04 [DEBUG] Text=[package], Token=[2], Pos=[test.proto:3:1] called from lexer.go:139
2020/12/04 21:05:04 [DEBUG] Text=[package], Token=[2], Pos=[test.proto:3:1] called from lexer.go:139
2020/12/04 21:05:04 [DEBUG] Text=[package], Token=[2], Pos=[test.proto:3:1] called from parser.go:44
2020/12/04 21:05:04 [DEBUG] Text=[package], Token=[29], Pos=[test.proto:3:1] called from lexer.go:139
2020/12/04 21:05:04 [DEBUG] Text=[package], Token=[29], Pos=[test.proto:3:1] called from lexer.go:139
2020/12/04 21:05:04 [DEBUG] Text=[foobar], Token=[2], Pos=[test.proto:3:9] called from fullIdent.go:8
2020/12/04 21:05:04 [DEBUG] Text=[;], Token=[8], Pos=[test.proto:3:15] called from fullIdent.go:15
2020/12/04 21:05:04 [DEBUG] Text=[;], Token=[8], Pos=[test.proto:3:15] called from package.go:55
2020/12/04 21:05:04 [DEBUG] Text=[option], Token=[2], Pos=[test.proto:5:1] called from lexer.go:139
2020/12/04 21:05:04 [DEBUG] Text=[option], Token=[2], Pos=[test.proto:5:1] called from lexer.go:139
2020/12/04 21:05:04 [DEBUG] Text=[option], Token=[2], Pos=[test.proto:5:1] called from parser.go:44
2020/12/04 21:05:04 [DEBUG] Text=[option], Token=[30], Pos=[test.proto:5:1] called from lexer.go:139
2020/12/04 21:05:04 [DEBUG] Text=[option], Token=[30], Pos=[test.proto:5:1] called from lexer.go:139
2020/12/04 21:05:04 [DEBUG] Text=[java_package], Token=[2], Pos=[test.proto:5:8] called from option.go:153
2020/12/04 21:05:04 [DEBUG] Text=[=], Token=[10], Pos=[test.proto:5:21] called from option.go:175
2020/12/04 21:05:04 [DEBUG] Text=[=], Token=[10], Pos=[test.proto:5:21] called from option.go:58
2020/12/04 21:05:04 [DEBUG] Text=["], Token=[11], Pos=[test.proto:5:23] called from lexer.go:154
2020/12/04 21:05:04 [DEBUG] Text=["com.test.foo.bar"], Token=[6], Pos=[test.proto:5:23] called from lexer.go:139
2020/12/04 21:05:04 [DEBUG] Text=[;], Token=[8], Pos=[test.proto:5:41] called from lexer.go:139
2020/12/04 21:05:04 [DEBUG] Text=[;], Token=[8], Pos=[test.proto:5:41] called from option.go:68
2020/12/04 21:05:04 [DEBUG] Text=[message], Token=[2], Pos=[test.proto:7:1] called from lexer.go:139
2020/12/04 21:05:04 [DEBUG] Text=[message], Token=[2], Pos=[test.proto:7:1] called from lexer.go:139
2020/12/04 21:05:04 [DEBUG] Text=[message], Token=[2], Pos=[test.proto:7:1] called from parser.go:44
2020/12/04 21:05:04 [DEBUG] Text=[message], Token=[26], Pos=[test.proto:7:1] called from lexer.go:139
2020/12/04 21:05:04 [DEBUG] Text=[message], Token=[26], Pos=[test.proto:7:1] called from lexer.go:139
2020/12/04 21:05:04 [DEBUG] Text=[TestMessage], Token=[2], Pos=[test.proto:7:9] called from message.go:76
2020/12/04 21:05:04 [DEBUG] Text=[{], Token=[14], Pos=[test.proto:7:21] called from message.go:106
2020/12/04 21:05:04 [DEBUG] Text=[string], Token=[2], Pos=[test.proto:7:23] called from lexer.go:139
2020/12/04 21:05:04 [DEBUG] Text=[string], Token=[2], Pos=[test.proto:7:23] called from message.go:114
2020/12/04 21:05:04 [DEBUG] Text=[string], Token=[2], Pos=[test.proto:7:23] called from lexer.go:139
2020/12/04 21:05:04 [DEBUG] Text=[string], Token=[2], Pos=[test.proto:7:23] called from lexer.go:139
2020/12/04 21:05:04 [DEBUG] Text=[string], Token=[2], Pos=[test.proto:7:23] called from lexer.go:139
2020/12/04 21:05:04 [DEBUG] Text=[string], Token=[2], Pos=[test.proto:7:23] called from lexer.go:139
2020/12/04 21:05:04 [DEBUG] Text=[string], Token=[2], Pos=[test.proto:7:23] called from lexer.go:139
2020/12/04 21:05:04 [DEBUG] Text=[string], Token=[2], Pos=[test.proto:7:23] called from field.go:210
2020/12/04 21:05:04 [DEBUG] Text=[test_field], Token=[2], Pos=[test.proto:7:30] called from field.go:79
2020/12/04 21:05:04 [DEBUG] Text=[=], Token=[10], Pos=[test.proto:7:41] called from field.go:85
2020/12/04 21:05:04 [DEBUG] Text=[1], Token=[3], Pos=[test.proto:7:43] called from lexer.go:139
2020/12/04 21:05:04 [DEBUG] Text=[;], Token=[8], Pos=[test.proto:7:44] called from field.go:119
2020/12/04 21:05:04 [DEBUG] Text=[;], Token=[8], Pos=[test.proto:7:44] called from field.go:100
2020/12/04 21:05:04 [DEBUG] Text=[}], Token=[15], Pos=[test.proto:7:46] called from lexer.go:139
2020/12/04 21:05:04 [DEBUG] Text=[}], Token=[15], Pos=[test.proto:7:46] called from lexer.go:139
2020/12/04 21:05:04 [DEBUG] Text=[}], Token=[15], Pos=[test.proto:7:46] called from lexer.go:139
2020/12/04 21:05:04 [DEBUG] Text=[}], Token=[15], Pos=[test.proto:7:46] called from message.go:151
2020/12/04 21:05:04 [DEBUG] Text=[], Token=[1], Pos=[test.proto:7:47] called from lexer.go:189
2020/12/04 21:05:04 [DEBUG] Text=[], Token=[1], Pos=[test.proto:7:47] called from lexer.go:139
2020/12/04 21:05:04 [DEBUG] Text=[], Token=[1], Pos=[test.proto:7:47] called from lexer.go:139
2020/12/04 21:05:04 [DEBUG] Text=[], Token=[1], Pos=[test.proto:7:47] called from parser.go:44
[test.proto:7:23] Found an incorrect indentation style "   ". "  " is correct.

Running protolint on one of my v3 proto files resulted in the following error:
panic: runtime error: invalid memory address or nil pointer dereference

After some tests the cause was found: the protolint parser doesn't accept a semicolon after a statement block in curly brackets, e.g. after service/rpc/method:
service LazyService {}; // Semicolon causing runtime error

According to the Protobuf language specification the semicolon is not allowed behind curly brackets, but the Protobuf generator does accept it. Moreover the error message is providing no hint about the cause (even if using the verbose flag). Therefore I'd recommend to adapt the parser to accept the semicolon even if not specified.

Hi, excellent tool, we're considering using it as part of our CI environment.

The one issue at have is that the output format is not supported by any of the jenkins plugins we use (and junit isn't really the right format for a linter to output).

I'm considering adding protolint parsers to the plugins we use (warnings-ng and any that use violatons lib), if you think that's OK? Unless there is a more common standard linting format that this tool could use?

Thanks

I was looking for a protobuf schema validator (without creating language class files 🙃 ) and found this project.

I tried validation a simple message with unknown field types but it did not invalidate the file. Is there an option/config I missed?

I'm working on it at the moment.

Thank you for developing a great tool. I recently started to use this tool because I want to use the fixer feature. However, I realized there's no way to check diff without actually fixing my files. Could you consider adding diff feature so I can go ahead applying the changes without worries?

That's because it causes trouble calculating the relative path of each target proto file.

I have tried to run protolinter on the proto files with swagger annotations, but itseems to break the linter with below error:

found ""max_length"(Token=2, Pos=..\protos\test.proto:179:5)" but expected [}] at C:/Users/uname/go/src/github.com/yoheimuta/go-protoparser/parser/field.go:243:found "ma
x_length" but expected at C:/Users/uname/go/src/github.com/yoheimuta/go-protoparser/internal/lexer/emptyStatement.go:16

Below is a sample proto message with annotations:

message UserCredentials {
option (grpc.gateway.protoc_gen_swagger.options.openapiv2_schema) = {
example: { value: '{ "email_id": "[email protected]", "password": "password@123"}' }
};
string email_id = 1[(grpc.gateway.protoc_gen_swagger.options.openapiv2_field) = {
pattern: "^-!#$%&'*+\/0-9=?A-Z^_a-z{|}~@a-zA-Z0-9\.a-zA-Z+$"
max_length: 254
min_length: 1
description: "Enter user email"
}];
string password = 2[(grpc.gateway.protoc_gen_swagger.options.openapiv2_field) = {
description: "Enter user password"
}];
}

Hi, Tried to apply linter on a directory with multiple folders with proto files, no response from linter.

Example:
Main Directory->
-Folder1-> protofile1
-Folder2-> protofile2
-Folder3-> protofile3
It works when i remove folder2 and folder3. Let me know whether I missed something

Currently, the behaviour when a parsing error occurs is to fail with a message such as found "{" but expected [constant]. Use -v for more details and an exit code of 1. There is no indication of which file has failed without using the -v flag, which is incredibly verbose, and goes to stderr. The exit code of 1 also makes it hard to differentiate from a "normal" linting error.

For use in CI and integration with other linting tools, it would be nice if:

• error codes differed based on error type; eg 1 for linting errors, 2 for parsing, 3 for (other relevant issue), etc. If both a lint and a parse error occurs, return the higher one. For extra complexity, use fancy binary logic, so 3 might be linting+parsing errors (01 + 10), in which case 4 would be the next relevant issue.
• "failure to parse" reports the filename, even without -v; in a similar output to the current error parsing format.
• "failure to parse" errors didn't stop the linter. It's fine if the linter can't handle the rest of the current file, but when linting an entire directory, there could be other files which have errors to be reported.

A stretch goal and dream for me would also be if you allowed multiple output modes; similar to what shellcheck offers, with json/gcc/diff options; but of course, thats no easy task, and so I'll just leave that as an afterthought. (EDIT: JSON added in #104)

Otherwise, thank you for the great tool!

The following proto does not get any indentation warnings raised, even though the values in the [] are all over the place. Is this intended?

syntax = "proto3";

message Foo {
  string bar = 1 [
                     // comment
               deprecated=true
                                 ];
}

Why rule named PACKAGE_NAME_LOWER_CASE additionally checks extraneous rules?

Verifies that the package name only contains lowercase letters [ digits and/or periods].

According to the https://developers.google.com/protocol-buffers/docs/style.

Package name should be in lowercase, and should correspond to the directory hierarchy. e.g., 
if a file is in my/package/, then the package name should be my.package.

We have directories like my/some-service and package my.some_service. But protolint prohibits it without proofs :(

P.S. I suggest renaming the rule to PACKAGE_NAME_FORMAT and let it be configured using the regex from the .protolint.yaml.

I started to implement a custom rule within my own plugin but got a segmentation fault when trying to use it with protolint. To make sure that it is a problem of my own plugin I compiled your example plugin, but I got the same error.
My system:

• Ubuntu 18.04.2
• go 1.12.9 (linux/amd64)

My steps in detail:

• Build and install protolint
• Build example plugin: go build -buildmode=plugin
• Make sure protolint and plugin.so have execution permission
• Run protolint: protolint lint -v -plugin ./plugin.so .

Error output:

2019-08-30T13:43:46.993+0200 [DEBUG] plugin: starting plugin: path=/bin/sh args=[sh, -c, ./plugin.so]
2019-08-30T13:43:46.993+0200 [DEBUG] plugin: plugin started: path=/bin/sh pid=3763
2019-08-30T13:43:46.993+0200 [DEBUG] plugin: waiting for RPC address: path=/bin/sh
2019-08-30T13:43:47.131+0200 [DEBUG] plugin.sh: Segmentation fault (core dumped)
invalid value "./plugin.so" for flag -plugin: failed client.Client(), err=Unrecognized remote plugin message: 

This usually means that the plugin is either invalid or simply
needs to be recompiled to support the latest protocol.
Usage of lint:
  -config_dir_path string
    	path/to/protolint.yaml
  -fix
    	mode that the command line can automatically fix some of the problems
  -plugin value
    	plugins to provide custom lint rule set. Note that it's necessary to specify it as path format'
  -reporter value
    	formatter to output results in the specific format. Available reporters are "plain"(default) and "junit".
  -v	verbose output that includes parsing process details

Did I miss anything? Do you have an idea why I'm getting the segmentation fault?

It would be nice if protolint could output it's error messages in JUnit xml format.

This would make it easy to integrate with Jenkins and other CI tools for reporting linting errors.

People love linting! Lets let the Javascript projects join in on the fun too.

I installed the protolint in my macOS v10.15 with
go get -u -v github.com/yoheimuta/protolint/cmd/protolint

but after run protolint command in the terminal I received:
protolint: command not found

I also tried restart the terminal and mac but didn't work.

Any help?

Using options on oneof fields causes a parse error in protolint, despite protoc not having an issue with it.

Example use: https://github.com/mwitkow/go-proto-validators/blob/fef10b927e0a0207085b8f8fc58a01f9a096d9e6/test/validator_proto3_oneof.proto#L25

found "("(Token=12, Pos=test.proto:25:12) but expected [fieldName] at C:/Users/user/go/src/github.com/yoheimuta/go-protoparser/parser/oneof.go:155

The trailing comma after the field2 value in this scenario breaks parsing.
This is a valid proto, and should not be the case.

    option (item) = {
      field: "data",
      field2: "data2",
    };

https://developers.google.com/protocol-buffers/docs/style#enums

enum FooBar {
  FOO_BAR_UNSPECIFIED = 0;
  FOO_BAR_FIRST_VALUE = 1;
  FOO_BAR_SECOND_VALUE = 2;
}

Prefer prefixing enum values instead of surrounding them in an enclosing message.

It would be nice to have protolint output it's version string when outputting the help information.

Some possibilities:

protolint output could be amended to output version information.
protolint -version could output just the version information.
protolint -help could output the help/usage information and version information.

I have a protolint plugin with some custom defined rules. The protolint output should be written to a file. I use the following bash script to execute protolint (just a part of the script):

...
exec 2>$PROTOLINT_RESULT_FILE
protolint lint -plugin <custom plugin> -reporter junit .
...

After executing the script the $PROTOLINT_RESULT_FILE contains the following:

2019-10-07T09:35:25.066Z [DEBUG] plugin: starting plugin: path=/bin/sh args=[sh, -c, /usr/local/bin/kuka_rules]
2019-10-07T09:35:25.069Z [DEBUG] plugin: plugin started: path=/bin/sh pid=19
2019-10-07T09:35:25.069Z [DEBUG] plugin: waiting for RPC address: path=/bin/sh
2019-10-07T09:35:25.079Z [DEBUG] plugin.sh: plugin address: address=/tmp/plugin587097189 network=unix timestamp=2019-10-07T09:35:25.079Z
2019-10-07T09:35:25.081Z [DEBUG] plugin: using plugin: version=1
<?xml version="1.0" encoding="UTF-8"?>
  <testsuites>
      <testsuite tests="1" failures="0" time="0">
          <package>net.protolint</package>
          <testcase classname="net.protolint.ALL_RULES" name="All Rules" time="0"></testcase>
      </testsuite>
  </testsuites>

I saw that the plugin mechanism of protolint uses the hclog logger. Its default output is stderr. The jUnitReporter of protolint also uses stderr. Which collides in my opinion.

How can I get rid of the go-plugin DEBUG log output in the protolint result file?

Used versions:

• protolint v0.17.0
• Go 1.12

Do you have any idea?

Hi

Is there a way to support the Google API Linter - https://linter.aip.dev/

Issue #27 introduced support for the "extend" keyword.
Unfortunately the indent rule doesn't handle it correctly. It seems to expect no indentation for the extension content (https://github.com/googleapis/googleapis/blob/master/google/api/annotations.proto):
[google\api\annotations.proto:30:3] Found an incorrect indentation style " ". "" is correct.
[google\api\annotations.proto:29:3] Found an incorrect indentation style " ". "" is correct.

I'm working on it backed by the plugin mechanism.

Again, thanks for putting this project together.

As I mentioned in PR #24, the next logical step would be to get this into Visual Studio Code so that users can lint their .proto files as they type.

I put together a MVP here (https://github.com/jpreese/vscode-protobuflint). It uses your tool on the backend, and renders any linting errors to the editor.

I haven't cut a release to the marketplace yet, but just wanted to let you know it's in the works.

Given the following proto file:

syntax = "proto2";

enum TestNegativeValue {
  NEGATIVE_CONSTANT = -1;
  ZERO_CONSTANT = 0;
  POSITIVE_CONSTANT = 1;
}

protolint fails on the negative enum constant:

$ protolint negative_enum_val.proto 
found "\"-\"(Token=0, Pos=negative_enum_val.proto:4:23)" but expected [intLit] at /go/pkg/mod/github.com/yoheimuta/go-protoparser/[email protected]/parser/enum.go:242:found "-" but expected [;]. Use -v for more details

$ echo $?
2

Using the Linux 0.26.0 release protolint_0.26.0_Linux_x86_64.tar.gz

Not an issue for protoc. For now I'm excluding certain proto files that have negative enums in the protolint config file.

When linting proto files in other than root folder, overrides to separate file paths must be written 2 times to ensure proper handling in both OS versions.

This variant is properly handled in UNIX only:

# Lint directives.
lint:
  # Linter files to ignore.
  ignores:
    - id: MESSAGE_NAMES_UPPER_CAMEL_CASE
      files:
        - ../proto/simple.proto

This variant is properly handled in Windows only:

# Lint directives.
lint:
  # Linter files to ignore.
  ignores:
    - id: MESSAGE_NAMES_UPPER_CAMEL_CASE
      files:
        - ..\proto\simple.proto

So to make it uniform one have to duplicate each path entry like this:

# Lint directives.
lint:
  # Linter files to ignore.
  ignores:
    - id: MESSAGE_NAMES_UPPER_CAMEL_CASE
      files:
        - ../proto/simple.proto
        - ..\proto\simple.proto

It would be great if UNIX paths will be properly accepted by Windows version of protolint.

Parsing breaks when including an option with an empty message within the option. The below snippet compiles fine in protoc, but doesn't parse with protolint.

syntax = "proto3";

service Foo {
  rpc Bar(Baz) returns (Baz) {
    option (opt) = {
      empty : {}
    };
  }
}

message Baz {}

It would be nice if the linter was able to check whether a rule is defined or not.
This would likely have helped avoid #116, where rules seemed to be ignored because of trailing whitespace.

This should be used to check the rules specified in .add and .remove in the config, as well as protolint:disable directives.

ref. #139 (comment)

vs. -fix option:

• -fix option is so conservative that it doesn't force an opinionated format by following the explicitly specified rules with granular settings. While it's useful, sometimes it's too complicated to implement editing only a small fraction of the file content.
• format command is supposed to be an opinionated feature so that it can fully rewrite the file content according to the choice of some predefined styles. It would be expected to complement the -fix option.

For example, I presume it results in easier support for the file structure guidelines.

It'd be nice to have some exceptions for lines exceeding max line length (without explicit disable macros) since it's sometimes not feasible to split in proto files for cases like long URLs and import paths.

Just for reference, Google's C++ Style Guide and Java Style Guide both specify some exceptions and the same discussion would apply in protos although the Official Protocol Buffers Style Guide suggests to keep the line length without mentioning exceptions.

> $GOBIN/pl .
found "{" but expected [constant]

No line numbers or file names when an error is found