Vendoring lint rules instead of trusting a dependency
Rules you can read are rules you can argue with.
Placeholder article. The frontmatter and structure are real; the prose is a draft to exercise the layout and should be rewritten or removed before launch.
The tools/oxlint/anti-slop/ directory in this repository is a lint plugin that is not
installed from anywhere. It is source, checked in, with its own tests.
The argument for vendoring
A lint rule encodes a claim about what good code looks like here. Pulling that claim from a package means the claim can change under you, and it means nobody on the project has read it. Keeping it as source means the rule and its rationale are reviewable in the same pull request as the code it governs.
What the rules actually reject
They target low-evidence patterns — assertions that widen a known type and then narrow it
again, parameters typed as unknown or the broad object, dictionary types with no
declared keys. None of these are errors. All of them are places where the author knew
something the type system was not told.
The cost
Every vendored rule is a rule you maintain. That is the point: the maintenance is the review, and a rule nobody is willing to maintain is a rule nobody believed in.