Azure / Azure/typespec-azure

Add linter rule for models that are only used as spread sources

Open
#848 0 comments 0 reactions 0 assignees View on GitHub
feature lib:azure-core linter
Dominant language
TypeScript
Stars
27
Forks
90
Avg merge
1d 22h
Merged PRs (30d)
156

Description

### Clear and concise description of the problem

In general, models that are only referenced in spreads into other models are not things that we want to emit (note: spreading into `op` parameters is different). We *usually* "fix" the problem by erasing unreferenced models in our emitters, but that is work that shouldn't be necessary. Having a model also has the downside of a) us having to give it a (good) name and b) requires documentation. Neither of which are that helpful. It also risks introducing ghost breaking change warnings/confuse our generators if the models were not intended for reuse outside the scope of a given spec (i.e. they are not part of the public surface area in a library)

### Checklist

- [X] Follow our [Code of Conduct](https://github.com/azure/typespec-azure/blob/main/CODE_OF_CONDUCT.md)
- [X] Check that this issue is about the Azure libraries for typespec. For feature request in the typespec language or core libraries file it in the [TypeSpec repo](https://github.com/Microsoft/TypeSpec/issues/new/choose)
- [X] Read the [docs](https://azure.github.io/typespec-azure/).
- [X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

Contributor guide

Open the contributing guide

Research direction

Start by locating the existing Azure linter rules and their tests; the payload does not name specific files or entry points. Define the rule's scope from the issue: flag models used only as spread sources, exclude models spread into op parameters, and consider the work done when the intended cases are diagnosed without requiring emitter cleanup.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
tooling
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.