Skip to content

Document linter rule ID naming conventions in linter authoring docs #10856

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.

Sign up for GitHub

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

Merged
timotheeguerin merged 3 commits into from
Jun 1, 2026
Merged

Document linter rule ID naming conventions in linter authoring docs #10856

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
906f512
Initial plan
Copilot Jun 1, 2026
89201bb
docs: add linter rule naming guidance
Copilot Jun 1, 2026
8552679
docs: rename linter section heading
Copilot Jun 1, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 11 additions & 0 deletions website/src/content/docs/docs/extending-typespec/linters.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -62,6 +62,17 @@ export const requiredDocRule = createRule({
});
```

#### Naming convention

Rule names are user-facing in diagnostics, `tspconfig.yaml`, docs URLs, and suppression comments, so keep them concise and readable.

- Use short **kebab-case** names.
- Do **not** include the package or library name in `name`.
- `name` should be only the rule part (for example `no-foo`), not `@typespec/my-linter/no-foo`.
- Use `no-<thing>` when the rule bans a construct or usage.
- Use `use-<preferred-thing>` when the rule guides users toward a standard or preferred TypeSpec pattern.
- For domain-specific validation where `no-`/`use-` does not fit, use short subject-oriented names such as `<subject>-missing-<thing>` or `<subject>-invalid-<condition>`.

#### Define rules with options

Rules can accept user-configurable options via `defaultOptions` and `context.options`. When enabled with `true`, the rule uses the default options. When enabled with an object, the provided values override the defaults.
Expand Down
Loading