[tcgc] add client initialization usage #1664
Conversation
iscai-msft
requested review from
lmazuel,
m-nash,
srnagar,
joheredi,
bterlson,
markcowl,
allenjzhang and
timotheeguerin
as code owners
iscai-msft
changed the title
|
All changed packages have been documented.
Show changes
|
|
You can try these changes here
|
| export interface SdkInitializationType extends SdkModelType { | ||
| properties: SdkParameter[]; | ||
| export interface SdkInitializationType { | ||
| access: AccessFlags; |
There was a problem hiding this comment.
i've realized we can't modify the .access on our existing SdkInitializationType to denote whether a client is publicly or internally initialized. There is both the context that the client options model is used, and the client options model itself. In this case, the context that the client options model is used has access that depends on whether it's a client or og. However, that doesn't change the actual access of the client options model itself.
This is a breaking change, so want to call this out and will call it out more in our sync
| model: Model, | ||
| ): SdkInitializationType { | ||
| // convert to SDK type | ||
| const existingModel = context.modelsMap?.get(model) as SdkModelType<SdkParameter> | undefined; |
There was a problem hiding this comment.
do we allow to reuse model in operation as a client initialization model? if so, can we have a test? if not, we could return directly and shall have some lint.
There was a problem hiding this comment.
@m-nash since c# appears to be the main sdk using client initialization model generation, is there anything precluding us from having a model be used in both scenarios?
…m/Azure/typespec-azure into tcgc/addClientInitializationUsage
fixes #1518, #1707