Re-export bufbuild_es message types

[thesiti92]

Is your feature request related to a problem? Please describe.
What's the problem? For example, "I'm always frustrated when..."

Right now its annoying to keep a top level @buf/<repo>.bufbuild_connect-web package's version of its bufbuild_es packages in sync with another top level @buf/<repo>.bufbuild_es package's version of the same types. We want to use the protobuf types as interfaces for redux state, etc...

When using mainline protos its not a huge issue since they have real versions with commit hashes to match up, but right now we're working with draft protos where the package.json versions for them are

    "@buf/repo.bufbuild_connect-web": "trunk",
    "@buf/repo.bufbuild_es": "trunk",

Describe the solution you'd like

It would make all this package nonsense way easier if you guys could just reexport the contents of the @buf/<repo>.bufbuild_es package from a subdirectory or something.

Describe alternatives you've considered

Alternatively, you guys could have some yarn recipe for keeping them in sync.

Additional context
were using draft protos to follow our staging api's protos (mainline trunk) and when a feature branch is cut then we publish the mainline protos to bsr.

[thesiti92]

just moved to local generation for now, but in the future this feature would make the remote plugins way easier to use in node

[timostamm]

@thesiti92, for the eliza module, this path imports the service:

@buf/bufbuild_eliza.bufbuild_connect-es/buf/connect/demo/eliza/v1/eliza_connect.js

And this path imports the messages:

@buf/bufbuild_eliza.bufbuild_es/buf/connect/demo/eliza/v1/eliza_pb.js

Are you suggesting that the first path also re-exports all messages from the second path, so that you only have to import from the first path in your application code?

[thesiti92]

Yeah that would be convenient. Keeping the @buf/bufbuild_eliza.bufbuild_es and @buf/bufbuild_eliza.bufbuild_connect-web package versions in sync is a pain when you are using draft protos since the version in the package json is pinned to <draft-name> and not a real package version.