The name is funny. The policy is serious.
ai-deslop 0.4.6 is a real Oxlint plugin. Its recommended config enables its selected rules as errors and turns on type-aware linting. The pack rejects patterns that its authors connect with weak type evidence, wasteful code, and low-value tests. It also rejects choices that may be valid local style, including module mocks, runtime typeof checks, and the word shape in locally owned symbol names.[1]
That mix is the point. A rule pack can contain a useful bug detector beside a strong architectural preference. The package name does not tell you which one you are enabling. Read the implementation and examples before the config enters continuous integration.
Lint can make an argument repeatable. It cannot make the argument correct.
Oxlint makes custom policy fast, but the route is still young.
Oxlint documents support for custom JavaScript plugins and compatibility with most of the ESLint 9 plugin API. The same page labels JavaScript plugins alpha and under active development.[2] That means two things need separate owners. One owner decides whether a rule fits the codebase. Another watches the plugin host, version pairing, and failure behavior.
A fast linter reduces the cost of running policy. It does not reduce the cost of a bad block. When an opinionated rule stops a release, the repository needs a rationale, examples of accepted and rejected code, a scoped escape hatch, and a person who will answer the next edge case.
Established rules still need local judgment.
The typescript-eslint documentation calls explicit any an escape from the type system. It also says the rule is not always applicable and lists cases where any can be harder to avoid.[3] That is a useful model for newer rules. State the risk. Show a safer route. Keep exceptions visible. Do not pretend one syntax ban proves program correctness.
Start with rules that catch a behavior your team can demonstrate. A repeated function call inside adjacent assertions can run work twice and observe two states. A rule can point to that pattern. The review still decides whether the repeated call matters in that test.
The exact release gave us a mixed test record.
We inspected tag v0.4.6 at commit 3351e6e64e1f8e6f5807ecc16d42d8a80f4a0f79. The repository's npm run check command built the package, ran Oxlint over the source, and completed TypeScript checking with no reported errors. The full Vitest run passed 127 of 128 tests. One Tailwind design-system case exceeded its 30-second timeout. A focused rerun reached the same timeout in the same parameterized case.[1]
That result does not prove a rule is wrong. It does mean the exact release did not give us a clean test run on this Linux host. We did not raise the repository's own per-test timeout, edit the fixture, or install the plugin into a working project. Treat the package as a candidate with a useful rule catalog, not as a merge gate ready for blind adoption.
Adopt the argument, then adopt the rule.
Pin the package version and Oxlint version. Choose one rule. Run it in warning mode against a representative corpus. Save true positives, false positives, runtime, and the repair reviewers accepted. Write the rationale beside the config. Name an owner and an expiry date for exceptions.
Move to review mode when the warning produces useful discussions with tolerable noise. Move to blocking only after a clean trial on real pull requests and a tested bypass that leaves a visible record. If nobody will own the rule, leave it out. A repository policy should survive without the package's marketing label.