buf.lock dependencies not resolving

[derekperkins]

I'm using Goland (2022.2) with buf 1.7.0 and non-well-known-types are not resolving and show an error, even though . Unlike #37, well known types work just fine. Running buf build and buf generate work as expected with no errors, and the generated code uses the date package. This is my first time importing an external dependency, so I am not sure if this worked before or not.

conversation here: https://bufbuild.slack.com/archives/CRZ680FUH/p1661382658841319

Here's a barebones example that I believe should reproduce the issue, though I haven't tested it locally.

syntax = "proto3";

package billing;

import "google/type/date.proto";
import "google/protobuf/timestamp.proto";

message Test
  google.type.Date date = 1;
  google.protobuf.Timestamp timestamp = 2;
}

buf.yaml

version: v1
build:
  excludes:
    - bazel-bin
    - bazel-go.nozzle.io
    - bazel-out
    - bazel-testlogs

deps:
 - buf.build/googleapis/googleapis

lint:
  use:
    - DEFAULT
breaking:
  use:
    - FILE

buf.gen.yaml

version: v1
managed:
  enabled: true
  go_package_prefix:
    default: go.nozzle.io
    except:
      - buf.build/googleapis/googleapis
plugins:
  - name: go
    out: .
    opt: paths=source_relative
  - name: go-grpc
    out: .
    opt:
      - paths=source_relative
      - require_unimplemented_servers=false
  - name: go-json
    out: .
    opt:
      - paths=source_relative
      - enums_as_ints=false
      - emit_defaults=false
      - orig_name=false
      - allow_unknown=false

buf.lock

version: v1
deps:
  - remote: buf.build
    owner: googleapis
    repository: googleapis
    commit: 80720a488c9a414bb8d4a9f811084989

[fkorotkov]

@derekperkins what do you see in the "External Libraries" panel in Project View?

If you don't see then we'll need a bit more details about your machine setup. Which version of OS are you using and have you override any of the Buf related configs like BUF_CACHE_DIR?

[derekperkins]

It's actually resolving now, I'm not sure what changed. Maybe it just took a while to propagate? It was probably 30 minutes yesterday that it was erroring. As I continue to iterate today, I'm seeing a similar issue again today where buf generate works great, but IntelliJ is lagging. Can I force refresh that external library?

[fkorotkov]

@derekperkins what's your OS? I wonder if there is an issue when Goland is not getting file system updates. Next time could you please try to invoke File -> Reload All from Disk which will force a sync between internal virtual FS and the real one.

[derekperkins]

MacOS 12.5.1. Restarting didn't fix the issue and neither did reloading files from disk.

It's possible I may be triggering a different bug now, as my issue is around the import of a buf module in a local workspace.

[derekperkins]

It suggests the auto-import based on the root relative path, vs resolving based on the module it lives in. My module is defined in /proto

buf.yaml

version: v1
name: buf.build/nozzle/nozzle
deps:
 - buf.build/googleapis/googleapis

[fkorotkov]

The resolution is based of location of buf.yaml. The plugin basically goes up the file tree until it sees buf.yaml Do you have buf.yaml for your /proto module?

[derekperkins]

We have a top level buf.yaml that ignores the proto directory, handling all our pre-consolidated proto management using the buf style guide. The buf.yaml under the proto directory is for the module. It feels like the plugin is trying to use /buf.yaml instead of /proto/buf.yaml, even though I'm in /proto/nozzle/billing/v1/*.proto

file layout

.
├── buf.gen.yaml
├── buf.yaml
└── proto
    ├── buf.gen.yaml
    ├── buf.lock
    ├── buf.yaml
    ├── gen
    ├── nozzle
    │   ├── billing
    │   │   └── v1
    │   │       ├── plan.proto
    │   │       ├── subscription.proto
    │   │       └── usage.proto
    └── protohelpers

/proto/buf.yaml

version: v1
name: buf.build/nozzle/nozzle

deps:
 - buf.build/googleapis/googleapis

lint:
  use:
    - DEFAULT
    - COMMENT_ENUM
    - COMMENT_MESSAGE
    - COMMENT_RPC
    - COMMENT_SERVICE
    - UNARY_RPC
    - PACKAGE_NO_IMPORT_CYCLE

breaking:
  use:
    - FILE

[derekperkins]

This is still an issue. The plugin tries to autocomplete from the root of our repo rather than the root of the buf module, which is /proto

[pkwarren]

Is this still an issue with the latest version of the plugin (0.4.1)? We've made several enhancements to how module dependencies are resolved.

I'd also suggest looking at upgrading to the latest version of buf and the v2 configuration files: https://buf.build/docs/migration-guides/migrate-v2-config-files. Those are now fully supported by the plugin and allow you to define a buf.yaml at the root of your project but have one or more modules in subdirectories (replacing buf.work.yaml).