microsoft / microsoft/typespec
Access decorator (internal/public)
- Dominant language
- Java
- Stars
- 5.9k
- Forks
- 394
- Avg merge
- 1d 23h
- Merged PRs (30d)
- 104
Description
### Clear and concise description of the problem
It's a pretty consistent need in the client emitter world, to be able to indicate that an operation or a model should have be exposed as internal or public. By default, client emitters will generate all operations as public, and automatically solve the set of public models by verifying what is used by operations (and hiding the rest). There are a few scenarios where the "access" override was useful:
- Want to generate an operation as internal (to allow a customization as public to call the internal operation).
- A model is added for customization purposes, and is not used by generated code (therefore hidden by default).
- A model only SDK will generate nothing by default (EventGrid).
TCGC related doc: https://azure.github.io/typespec-azure/docs/howtos/Client%20Generation/03convenient#make-methods-privateinternal
Comments about what TCGC team uncovered:
- Marking an operation "internal" should propagate it to the models used by that operation (with of course some resolution if part of those models are used by other operations)
- Marking a based class as internal, should mark all subclasses as internal
- Explicitly marking a model with an access should be more important than any automatic resolution
- Conflict may happen, and may be treated as "garbage in, garbage out" or raised as linter, or error (TBD)
### Checklist
- [X] Follow our [Code of Conduct](https://github.com/microsoft/typespec/blob/main/CODE_OF_CONDUCT.md)
- [X] Read the [docs](https://typespec.io/docs/).
- [X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.
Contributor guide
Assessment
This issue has not been assessed yet.