search

microsoft / typespec

https://typespec.io/
MIT License
4.48k stars 210 forks source link

Make the `@typespec/http-client-csharp` emitter a real dependency when called by azure emitter #4342

Closed ArcturusZhang closed 1 week ago

ArcturusZhang commented 1 month ago

Now the @typespec/http-client-csharp behaves still like an emitter when called by the azure emitter, everything has already been emitted to the disk when it returns to the azure emitter. We might need to let the csharp emitter behave like a dependency when we call it from azure plugin, so that we could get those useful in memory models, such as the SdkContext object.

ArcturusZhang commented 1 month ago

For instance, the @typespec/http-client-csharp emitter could export another function like:

export function doSomething(context: EmitContext<T extends NetEmitterOptions>): [SdkContext, CodeModel] {}

and the azure emitter could call this method in its $onEmit function, as well as the $onEmit in @typespec/http-client-csharp.

This might have overlap with the new emitter framework or something? It might need more discussion before we could do something

chunyu3 commented 1 month ago

it is our first step to export a large granularity API( the whole model), in the future, we may need export less granularity API (such as getClient), then in the follow-up emitter we can choose valid granularity API to use. in that case, it will allow follow-up emitter to do more customization.

JoshLove-msft commented 2 weeks ago

tspCodeModel.json should not be part of our public contract. It is important that we own the generation end-to-end. If we expose an API that exports the tspCodeModel.json, then it becomes part of the public contract.

Customization happens at the TCGC layer in the TypeGraph or downstream in the generator plugins. It shouldn't happen in tspCodeModel.json.

@ArcturusZhang can you clarify what problem we are trying to solve here?

ArcturusZhang commented 2 weeks ago

The scenario we are trying to solve is that, typespec-azure-resource-manager provides an API getArmResources to let us parse the spec to get the resource related information, and our generator should consume this information to generate those resources/collections/datas instead of like we used to have in autorest.csharp, we parse the spec to get which one is resource and which one is not. This is one of the advantage we could have in typespec, we should take and should not throw it away. Because this API is written in ts code, we could only call it in the emitter (azure emitter) but now the emitter here only writes a tspCodeModel.json, it does not pass it through with types, therefore it is impossible to figure that out and put the extra information in.

tspCodeModel.json should not be part of our public contract. It is important that we own the generation end-to-end. If we expose an API that exports the tspCodeModel.json, then it becomes part of the public contract.

I agree this, maybe we should try in this way?

ArcturusZhang commented 1 week ago

Closed in favor of https://github.com/Azure/autorest.csharp/issues/5120 since it is discussing a more general question.