`api-linter` fails to resolve the import path

[CuriousStork]

Environment details

• OS: Windows
• Package version: 1.70.2

Steps to reproduce

1. Create a project structured like below

   

   Set the test.proto text as

   syntax = "proto3";
   
   package api.v1;
   
   import "google/api/field_behavior.proto";
   
   message Test {
     string name = 1 [(google.api.field_behavior) = IDENTIFIER];
   }

   Set the field_behavior.proto text as https://github.com/googleapis/googleapis/blob/67fe1ece997ef298d8d86b026195ea2fd588c538/google/api/field_behavior.proto

2. Set the console cwd to the project root.

3. Run the console command

   api-linter --proto-path .\third_party .\api\v1\test.proto

   or

   api-linter --proto-path third_party .\api\v1\test.proto

This returns an error:

2025/08/07 14:56:11 api/v1/test.proto:5:8: could not resolve path "google/api/field_behavior.proto": open google\api\field_behavior.proto: The system cannot find the path specified.

The problem isn't reproduced via v. 1.67.*

[noahdietz]

@CuriousStork thanks for bumping this issue on the v2 issue. @quirogas and I will take a look at this soon. Apologies, we've been busy with that aforementioned migration :)

Initial thoughts though: We did some mucking around in the cmd/cli.go recently to fix/improve different api-linter invocation patterns that resulted to changes in how import paths are resolved. We were sure to use filepath libraries, but admittedly aren't testing on Windows machines. That is the likely area of issue. Given that it is broken in both the v1.x and v2 prereleases, my guess is it is in the same logic used by both and not something related to our usage of jhump/protoparse or bufbuild/protocompile. So, we should be able to find a fix that fits both versions.

[CuriousStork]

@noahdietz Hello, thank you for taking a look. Most likely it's not specific for Windows.

For the first time I encountered this in a Linux Docker container when tried upgrading api-linter from 1.67 to some recent stable version. I guess this issue was introduced in one of 1.69.* releases.

[noahdietz]

Took a min to repro this (on my macbook). This works until v1.69.0 when we started trying to fix a different bug in the CLI. I was able to repro the issue on the latest release v1.71.0.

Oddly enough, I was able to make it work when I provided the absolute path to a clone of googleapis/googleapis as the --proto-path value. When run from root and providing the absolute path of third_party it does not work. When I cd into the api/v1 directory (thus making cwd ./api/v1) and then provide an absolute path to the third_party directory above it in the same project, it works.

It is definitely related to our "resolve imports" logic @quirogas , likely around how imports "below"/within cwd are resolved.

[noahdietz]

I'll preface this with I think we should still be fixing this. Below is delving, not suggestion that anyone is "holding it wrong".

So our most recent fix is excluding import paths that exist in the cwd. This fixed #1465 nicely b.c the imports and the inputs (e.g. ./api/v1/test.proto in this case) were under the same subdirectory and we didn't want to parse the same stuff twice resulting in redefinition errors. The side effect is this bug where you run from project root, specify root-relative inputs, but have import statements that are "project root relative" but actually exist in a subdirectory of project root.

I changed the imports in test.proto to be third_party/google/api/field_behavior.proto and the --proto-path wasn't necessary.

[noahdietz]

I hacked together a fix based on my hunch above that resolved the issue with the repro #1544 (didn't updated any tests, hence failing test job). @quirogas is going to take another look at this.

[noahdietz]

FYI: This will be marked fixed once v2.x is released since #1545 fixes the issue.

[CuriousStork]

Hello,

As I understand, you will close the issue when v. 2.0 is released? Sounds great 👍

BTW, are you going to backport the fix into v. 1.*?

[noahdietz]

As I understand, you will close the issue when v. 2.0 is released? Sounds great 👍

Yep!

BTW, are you going to backport the fix into v. 1.*?

I think we should, but it may come post v2.0. We will have a v1 branch for a period of time for v1.x releases when absolutely necessary. This might be a good trial run of that.