Imported messages undefined

[BlakeMScurr]

Yoyoyo wassa,

I'm getting red underlining on perfectly valid messages if they're imported from other protobuf files. Not a hugely big deal, but has anyone else hit this?

[zxh0]

Hi @BlakeMScurr , could you upload a minimized demo/folder to let me reproduce your problem?

[RoarkeRandall]

I've noticed if I have two proto files in the same directory:

rpc/service.proto
rpc/messages.proto

where service.proto imports messages.proto like this:

import "messages.proto"

the extension will give an error, but generating the proto works fine.

if I change the import to:

import "rpc/messages.proto"

the extension will give no errors, but the proto generation will fail.

[yurishkuro]

I am having the same issue, have two files in the repository

model/proto/model.proto
model/proto/api_v2.proto

where the 2nd file has import "model.proto";, but the types imported that way are not recognized by the extension. I tried @RoarkeRandall's workaround of importing from a directory, e.g. import "proto/model.proto"; and import "model/proto/model.proto";, but no luck.

How does the extension resolve import paths anyway?

@RoarkeRandall to make your protoc run succeed you just need to give it the import directory via -I, so that rpc/messages.proto is a valid path. No idea why adding rpc/ helps with the extension error.

[dylan-bourque]

I'm having the same problem.

In messages.proto:

...
package mymessages;

message Request {
   ...
}

message Response {
   ...
}

In service.proto (in the same folder):

...
import "messages.proto";
package myservice;
service MyService {
   rpc MyMethod(mymessages.Request) return (mymessages.Response) {}
}

Both mymessages.Request and mymessages.Response have a red underline in the editor. The protoc ... command succeeds and generates correct, runnable code.

I tried various combinations of package names between the files and the messages in the included file always show as undefined.

[zxh0]

Thank you for these feedbacks, I will arrange some time to fix this issue 😊

[huan]

@zxh0 Thanks for your great vscode plugin for protocol buffers first.

I had run into this issue today, and hope it could be solved soon because it will really help when we are designing the protocol buffers in different files.

[zxh0]

Hi @zixia @dylan-bourque @yurishkuro @RoarkeRandall , very sorry for the slow response time.
Could you please upload some folder with problem .proto files (better with the settings.json file inside it) to let me easily reproduce this problem? thank you very much.

I have uploaded a folder to demonstrate @RoarkeRandall 's case (can not reproduce the problem), bellow is the foder structure and .vscode/settings.json & proto files:

.
├── .vscode
│   └── settings.json
└── rpc
    ├── messages.proto
    └── service.proto

// settings.json
{
    "protoc": {
        "path": "/usr/local/bin/protoc",
        "options": [
            "--proto_path=rpc",
            "--java_out=gen/java"
        ]
    }
}

// messages.proto
syntax = "proto3";

package rpc;

message MyReq {
  int32 field1=1;
}

message MyResp {
  int32 field1=1;
}

// service.proto
syntax = "proto3";

package rpc;

import "messages.proto";

service MyService {
  rpc foo (MyReq) returns (MyResp);
}

issue31.zip

[zxh0]

@yurishkuro under the hood, when you save some .proto file, the extension just invokes protoc to compile this file to some temporary directory, and in case of errors, it will parse protoc's output to generate diagnostic information.
the import path is read from .vscode/settings file and passed directly into protoc.

[yurishkuro]

@zxh0 I added the paths to my settings, like this

    "protoc": {
        "path": "/Users/yurishkuro/bin/protoc",
        "options": [
            "--proto_path=${workspaceRoot}/vendor/github.com/gogo/protobuf",
            "--proto_path=${workspaceRoot}/vendor/github.com/gogo/googleapis",
            "--proto_path=${workspaceRoot}/vendor/github.com/grpc-ecosystem/grpc-gateway",
            "--proto_path=${workspaceRoot}/model/proto"
        ]
    }

That seems to have broken the plugin altogether, as it doesn't highlight real errors anymore. Is there some diagnostic output from the plugin somewhere, e.g. which command it executes, what the errors are?

[huan]

@zxh0

My grpc protocol buffers file can be found at https://github.com/Chatie/grpc/blob/master/protobuf/wechaty-puppet.proto, please feel free to clone the repo and then I believe you can reproduce the followed screen shot after a save operation. (It will not display error if no save operation)

Description:

StartRequest & StartResponse are defined in import public "wechaty-puppet/base.proto";

[zxh0]

@yurishkuro I am afraid ${workspaceRoot} is not well understood by this extension, could you remove it (just leave the relative proto path) and try again?

[zxh0]

@zixia I could not trigger the error. The folder that I was open is grpc/protobuf.

[huan]

@zxh0 Thanks for the reply.

Working Version

I had just tested it again and found that it will be ok if you using vscode to open grpc/protobuf.

cd grpc
code protobuf

Not Working Version

However, if you open the repository root, then you can reproduce my problem.

cd grpc
code .

Conclusion

I guess that your code is using the relative path to the vscode opened folder for the import in protobuf file.

However, I believe the relative path in protobuf should based on the folder which contains the protobuf file, which should be grpc/protobuf in my case.

[zxh0]

@zixia you are welcome 😊
you can make the "not working version" work by adding a settings.json file into grpc/.vscode/, looks like this:

// grpc/.vscode/settings.json
{
  "protoc": {
      "options": [
          "--proto_path=protobuf" // relative to grpc/
      ]
  }
}

[huan]

@zxh0 Thanks, your workaround works like a charm!

My problem had been solved now, however, I'd like to suggest that we should change the source code to get the --proto_path from the __dirname from the proto file.

Thanks again for this great vscode plugin, Cheers!

[yurishkuro]

@zxh0 I haven't tried relative path or relative settings file, instead tried absolute path, and it didn't work

    "protoc": {
        "path": "/Users/yurishkuro/bin/protoc",
        "options": [
            "--proto_path=/Users/yurishkuro/golang/src/github.com/jaegertracing/jaeger/vendor/github.com/gogo/protobuf",
            "--proto_path=/Users/yurishkuro/golang/src/github.com/jaegertracing/jaeger/vendor/github.com/gogo/googleapis",
            "--proto_path=/Users/yurishkuro/golang/src/github.com/jaegertracing/jaeger/vendor/github.com/grpc-ecosystem/grpc-gateway",
            "--proto_path=/Users/yurishkuro/golang/src/github.com/jaegertracing/jaeger/model/proto"
        ]
    }

Is there a place to see some logs from the plugin? Ideally I would like to see the exact command used to run protoc, it would be much easier to resolve the issues.

[zxh0]

@yurishkuro I am sorry that the extension failed silently.

Currently, it only parses the proto syntax error that protoc outputed into stderr and ignores other errors, so it is hard to see what really happened.

But the work it did is really simple. When you modify and save a proto file, the extension will collect all --proto_path options from settings.json file (if there is one inside .vscode folder) and then send them with the modified proto file path into protoc to let protoc do the work. Then the extension receives and parses any output from stderr to generate diagnosis information.

So, if you open vscode from jaeger/ , and jaeger/.vscode/settings.json looks like this:

{
    "protoc": {
        "options": [
            "--proto_path=vendor/github.com/gogo/protobuf",
            "--proto_path=vendor/github.com/gogo/protobuf/protobuf",
            "--proto_path=vendor/github.com/gogo/googleapis",
            "--proto_path=vendor/github.com/grpc-ecosystem/grpc-gateway",
            "--proto_path=model/proto",
        ]
    }
}

Then, if you modify and save model/proto/model.proto , the extension will invoke protoc with the following options plus model.proto file:

BTW, I cloned jaeger project and locally modified model.proto to let it compile:

[yurishkuro]

@zxh0 this works for me now! Thanks for a great extension.

[johngrogg]

I've got what I think is the same basic issue, but in the opposite direction. We have a master proto file repo that our various service libraries get built out of. We've decided to have all imports relative to the repo root folder, but I can't figure out how to set the --proto_path value appropriately.

Example folder layouts:

.
├── .vscode
│   └── settings.json
├── service_one
│   ├── messages.proto
│   └── service.proto
└── service_two
    ├── messages.proto
    └── service.proto

An example of the imports for service_one/service.proto would then be:

import "google/api/annotations.proto";
import "google/api/http.proto";
import "google/protobuf/timestamp.proto";
import "service_one/messages.proto";

Any recommendations on the right --proto_path options value?

[zxh0]

hi @johngrogg just set --proto_path=.
here is a demo, hope it can help you
demo.zip

[Ondraceq]

Hi.
I'm having similar problem with using Remote - WSL extension.
I can "Go to Definition" of the message type and the imported file, but the message type gives an error, that the type is not defined.
I tried to add the path to the settings and add the "." variant as well. None of these worked for me. The errors have gone away when I specified full path from the workspace directory, but then it wouldn't compile.

Also - I tried it in Windows and it worked just fine - even without specifying anything in the settings.

I understand, that this could be a problem in Remote - WSL, since it's buggy, but the "Go to definition" feature works, so I think it could be solved from your side (but I have no experience writing extensions).

If it cannot be solved by your side - is there an option to turn off the errors? I really like the funtionality your extension has and wouldn't mind if no errors would be shown, but I don't like the red messages it now has.

[lucas860529hz]

try
"protoc": { "options": [ "--proto_path=${workspaceFolderBasename}" ] }
in vscode global setting.json.
It works for me.

[kjaebker]

using source relative makes this work for me

"protoc": {
        "options": [
            "--proto_path=source_relative"
        ]
    }

[EDIT: see response below from @nashikb this does not actually work and just causes a silent failure]

[nashikb]

using source relative makes this work for me

"protoc": {
        "options": [
            "--proto_path=source_relative"
        ]
    }

I don't think this is doing what you think it is. Unless your protos are in a directory called "source_relative", I think you're just seeing the tool silently fail to run. paths=source_relative is a --go_out flag, which doesn't seem to be "triggerable" from within vscode-proto3.

The only solution I've found for a proto repo set up as source_relative is to set -Ifoo/bar for all relative paths. Luckily, this seems to be configurable on in a per-workspace-specific setting.json. HIH!

[EDIT: But to be fair, the fact that vscode-proto3 doesn't log with the available VSCode logging methods is a pretty serious issue.]