-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
@clientName
shouldn't carry over
#233
Comments
From TypeSpec doc: https://typespec.io/docs/language-basics/models#is, |
Yeah by design decorator get carried over by the compiler and we don't have a way to opt out of that behavior but there is other way to make it behave the same. If you check the target of the decorator node and compare to the decorator node parent and make sure they match then it should only run in the case where client name was defined there |
Will compiler provide an API to distinguish if a decorator is a direct decorator? Have |
yes And no there will not be a compiler api to do the workaround. There will be an api at some point to make decorator not carry over. The workaround shouldn't be too hard to write.
|
@timotheeguerin do you know how to deal with augment decorator? I could not find a way to get the exact node for the referred node. |
Hhm yeah didn’t think of that… this one might be more tricky and maybe mean we need to prioritize designing a better solution in the compiler. what you can do is check the node of the augment decorator then see what it is the first argument and check the reference symbol to get the nodr |
When I tried to
|
So I think this issue only matters for model and operations names so maybe could limit to that for now. |
Similar to discussion we just had for
@friendlyName
,@clietnName
shouldn't carry overmodel is
Playground
The text was updated successfully, but these errors were encountered: