Module has already exported a member named 'ServerStreamingMethodResult'

[arnidan]

When defining gRPC stream methods across two different services, the TypeScript compiler raises an error indicating that the module has already exported a member named 'ServerStreamingMethodResult'.

ts-proto version: 1.167.3
ts-proto params: outputServices=nice-grpc,useExactTypes=false,outputIndex=true,esModuleInterop=true,importSuffix=.js

Steps to Reproduce

1. Define two different services, each with at least one server streaming method.
2. Generate TypeScript code using ts-proto.
3. Attempt to compile the generated TypeScript code.

[arnidan]

There is a code that reproduces the error: https://github.com/arnidan/ts-proto-issue-1002

Both generated FooService.ts and BarService.ts exports ServerStreamingMethodResult

https://github.com/arnidan/ts-proto-issue-1002/blob/main/ts/BarService.ts#L132C13-L132C40
https://github.com/arnidan/ts-proto-issue-1002/blob/main/ts/BarService.ts#L132C13-L132C40

[stephenh]

Hi @arnidan ; yeah, these conflicts are why I shied away from adding the outputIndex feature for awhile, it's just hard to anticipate what will/will not conflict.

I think there are probably a few approaches:

1. If outputIndex=true, then remove the export from the ServerStreamingMethodResult, and export none of them
2. The ts-poet Code datastructure technically knows all of it's export-d / defined symbols, so you could probably add some sort of generateBarrelExport([code1, code2, code3, ...]) utility method in ts-poet that generates export ... from ... statements but knows to only export the first symbol for each unique symbol name, and then alias the rest

Obviously 1 is a lot less work; but 2 is more robust as it'd handle all/future conflicts, and not just this one off.

If you'd like to submit a PR for either approach, that'd be great! Thanks!

[austin-liou]

I'm also running into this today :) I'll take a stab at a PR for option 1 because I'm super not confident in my ability to punch out option 2.

[stephenh]

This should be fixed by #1003 , thanks @austin-liou !

[austin-liou]

@stephenh thanks! Can I ask when new releases get cut :)

[stephenh]

Ah yeah, usually releases are auto-published, but the fix: prefix got lost on the way into main (it was in the PR title but not the commit message); I amended the commit to add fix: back, which published it, and changed a setting in Github to prevent this going forward.

[austin-liou]

Thanks!! Sorry about that - didn't quite know the convention