Feature Request: Ignore unknown extend options proto file and unused but imported proto file

[chenjie199234]

Here is a base context.
When we develop an app,the server and client may use different languages,and there are many different third party extend options proto files for every language.
Here is an example,it imports pbex.proto which is a third party extend options proto file for golang language.

pbex.proto
extend google.protobuf.FieldOptions {
    uint64 string_bytes_len_eq=160000;
}

syntax="proto3";
package test;
option go_package="test/api;api";
import "pbex/pbex.proto";
service test{
    rpc hello_world(hello_world_req)returns(hello_world_resp){
        option (pbex.method)="get";
    }
}

message hello_world_req{
    string str=1[(pbex.string_bytes_len_eq)=10];
}
message hello_world_resp{
    string str=1;
}

here is the generated code

var jspb = require('google-protobuf');
var goog = jspb;
var global = globalThis;

var pbex_pbex_pb = require('../pbex/pbex_pb.js');
goog.object.extend(proto, pbex_pbex_pb);
goog.exportSymbol('proto.test.hello_world_req', null, global);
goog.exportSymbol('proto.test.hello_world_resp', null, global);
......

The code will require('../pbex/pbex_pb.js'),and this shouldn't be generated.

As we known,the pbex.proto is not a normal proto file like this

first.proto
message firstmsg {
...
}

second.proto
import first.proto
message second {
   first.firstmsg f=1
}

In this case,i think require("first.js") is ok in second.js because the first.proto is a normal proto file,and it is actually used in second.proto.By the way,if the second.proto imported first.proto but not actually used in second.proto,it shouldn't exist in the generate code too.

There are lots of other third party extend options proto files we can use,like:
https://github.com/bufbuild/protoc-gen-validate
https://github.com/bufbuild/protovalidate

Here is the question:

1. Will this tool support so many third party extend options proto files?
2. Will these third party extend proto files' options impact this tool's (de)serialization?
3. If this tool will not compatible with these third party proto files,then why this tool's generate code import these third party extend proto files?
4. And how to fix the problem if user's project needs these third party proto files,but it's not for javascript.

The Feature Request is:

1. The imported proto file should be treated differently.Normal proto file or extend options proto file?Does the import proto file's content actually used?
2. each repo should only do their own job.This tool only do this tool's business.
3. These third party extend proto files repo should compatible with this tool actively.Not this tool compatible with these third party extend proto files repo actively.

So I think this tool should ignore these unknown extend proto files and unused but imported proto files
Before generate the normal code,there should be a precheck function to check whether the imported proto file should be generated or not.

[chenjie199234]

@dibenede
as the protobuf official repo said.the edition 2024 can fix this problem
i tested in edition 2024 with import option,it works
but this tools can't work in edition version
so maybe a precheck function is a good idea to fix this in this tool
or migrate to support edition 2024

[dibenede]

We support edition 2024: Edition GetMaximumEdition() const override { return Edition::EDITION_2024; }

Are you using using version 4.0.1 from our github releases or @protocolbuffers/protoc-gen-js?

[chenjie199234]

@dibenede