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, 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?
| Owner Name | bufbuild |
| Repo Name | connect-es |
| Full Name | bufbuild/connect-es |
| Language | TypeScript |
| Created Date | 2022-02-16 |
| Updated Date | 2023-03-24 |
| Star Count | 852 |
| Watcher Count | 20 |
| Fork Count | 33 |
| Issue Count | 17 |
| Issue Title | Created Date | Updated Date |
|---|