astral-sh/ruff · error · anyhow::Error
{e}
Error message
{e} What it means
`ty rule <name>` resolves the argument through the default lint registry; this anyhow wrapper just forwards the registry's `GetLintError` Display text. In practice the message is one of: `Unknown rule \`name\`` (optionally with `Did you mean \`...\`?` from fuzzy matching), `Removed rule \`name\``, or the prefixed-with-category form that suggests the unprefixed name — all meaning the given name does not resolve to a currently selectable lint.
Source
Thrown at crates/ty/src/rule.rs:53
let status = match self.status {
LintStatus::Stable { since } => format!("Stable (since {since})"),
LintStatus::Deprecated { since, reason } => {
format!("Deprecated (since {since}): {reason}")
}
LintStatus::Removed { since, reason } => format!("Removed (since {since}): {reason}"),
};
writeln!(f, "Default level: {} | {status}\n", self.default_level)?;
f.write_str(self.documentation.trim())
}
}
/// Explain a single rule.
pub(crate) fn rule(name: &str, format: HelpFormat) -> Result<()> {
let registry = default_lint_registry();
let lint = registry.get(name).map_err(|e| anyhow::anyhow!("{e}"))?;
let mut stdout = BufWriter::new(io::stdout().lock());
match format {
HelpFormat::Text => {
writeln!(stdout, "{}", Explanation::from_lint(&lint))?;
}
HelpFormat::Json => {
serde_json::to_writer_pretty(&mut stdout, &Explanation::from_lint(&lint))?;
}
}
Ok(())
}
/// Explain all rules.
pub(crate) fn rules(format: HelpFormat) -> Result<()> {
let registry = default_lint_registry();
let mut lints: Vec<LintId> = registry.lints().to_vec();
lints.sort_by_key(|l| l.name());View on GitHub (pinned to 672bb4edf0)
Solutions
- Apply the `Did you mean ...` suggestion printed in the error, if present
- List exact current names with `ty rules` (or `ty rules --format json`) and copy the name verbatim
- For a `Removed rule` message, read the removal version/reason shown by the registry and switch to the replacement rule
Example fix
# before ty rule unresolveed-import # after (use the suggested/actual name) ty rule unresolved-import
Defensive patterns
Strategy: validation
Validate before calling
ty rules | grep -Fx "$RULE_NAME" >/dev/null \
|| { echo "unknown rule: $RULE_NAME" >&2; exit 2; } Prevention
- Source rule names from `ty rules` output rather than docs or memory
- Prefer the `Did you mean` suggestion over hand-correcting typos
- When scripts loop over rule names, validate the list against `ty rules --format json` first
When it happens
Trigger: `ty rule unresolved-imports` (typo), passing a name that was removed in an earlier ty release (registry entry now `LintStatus::Removed`), or passing a name that still carries its category prefix; the registry suggests a close name when one exists.
Common situations: Copy-pasting rule names from older docs, issue threads, or `# ty: ignore` comments; scripts that loop over rule names and feed them to `ty rule`; shell-history typos.
Related errors
- Provided project path `{project}` is not a directory
- {flag} <reason> cannot contain newline characters
- The current working directory `{}` contains non-Unicode char
- `--watch` is not supported with uv workspace integration
- could not find task named `{}`
AI-assisted analysis of astral-sh/ruff@672bb4edf0 (2026-08-16).
Data as JSON: /api/errors/f93d393e7c050201.
Report an issue: GitHub.