False positive: Moving a type to another file while public importing is not incompatible?

[JanecekPetr]

Before (syntax and package declarations omitted):

• common.proto:

  // empty
  

• specific.proto:

  import "common.proto";
  
  enum BlaBlaType {
    BLA_BLA_TYPE_UNSPECIFIED = 0;
    BLA_BLA_TYPE_NONE = 1;
    BLA_BLA_TYPE_OF = 2;
    BLA_BLA_TYPE_YOUR = 3;
    BLA_BLA_TYPE_BUSINESS = 4;
  }

After:

• common.proto:

  enum BlaBlaType {
    BLA_BLA_TYPE_UNSPECIFIED = 0;
    BLA_BLA_TYPE_NONE = 1;
    BLA_BLA_TYPE_OF = 2;
    BLA_BLA_TYPE_YOUR = 3;
    BLA_BLA_TYPE_BUSINESS = 4;
  }

• specific.proto:

  import public "common.proto";
  
  // + some message using the enum

We got

Previously present enum "BlaBlaType" was deleted from file.

This seems unnecessary as the resulting effective set of available types is the same, or are we missing something?

[nicksnyder]

Moving this issue to bufbuild/buf since the behavior in question is implemented by the Buf CLI. The GitHub action just invokes the Buf CLI.

[bufdev]

The FILE breaking change level prevents moving across files, which deals with languages where types are imported on a per-file basis. For example, in C++, if your source code imports "specific.pb.h", moving the enum to common.proto means that the type will now be in "common.pb.h", potentially resulting in compile errors for source code that doesn't import "common.pb.h". Some languages may have their header files themselves import "common.pb.h", but the FILE level aims to be as strict as possible, as we can't assume how individual language generators work. You may want to reduce your breaking change category to PACKAGE, see https://buf.build/docs/breaking/rules#categories for more details.