Deslop ships Oxlint rules that flag AI-slop TypeScript patterns

What Deslop is

A project called Deslop, published to npm as ai-deslop, surfaced on Hacker News's front page on 13 October through a Show HN post. It is a set of opinionated Oxlint rules aimed at TypeScript produced by AI assistants — the repetitive, plausible-looking but weak constructs often described as slop. According to the project's GitHub repository, the goal is to reject patterns that compile cleanly yet discard the guarantees TypeScript exists to provide.

Deslop is not built entirely from scratch. The repository's credits note that its generic rules are vendored from dmmulroy/anti-slop, an MIT-licensed project by Dillon Mulroy, and combined with additional Deslop-specific rules, all renamed into a single deslop/* namespace.

The rule set

The largest group of recommended rules targets type safety. Several reject casts and widenings: nested as assertions, widening known values into unknown or object before narrowing them back down, and dictionary types built on unsafe escape hatches. Others forbid unknown in parameter, return and type-alias positions, along with plain object function inputs, on the grounds that these erase useful information at boundaries. Ad hoc typeof narrowing is rejected in favour of parsing values at the boundary, and object spreads that use a conditional empty object to omit fields are flagged. One rule goes beyond banning: it requires an inline justification comment for any non-const type assertion, and another removes type aliases that merely rename an existing type.

A second group covers general code quality. Adjacent eager filter/map passes are rejected in favour of lazy iterator pipelines, as are non-spread accumulator copies inside reducers — the README suggests pairing that rule with Oxlint's native no-accumulating-spread. The globals Reflect.apply and Reflect.get are rejected, as is the word "shape" in locally owned symbol names.

Tests get their own rules. Assertions that only check mock calls are flagged, Vitest and Jest module mocks are rejected outright, tests that merely verify a constant string contains substrings are called out, and repeated identical expect calls are reported with a nudge to reuse the result instead.

A set of opt-in rules handles cross-file duplication and cleanup: all-caps constants holding the same static value in different files, exactly duplicated object contracts, unnecessary named-import aliases, and non-canonical Tailwind CSS v4 class spellings. The last two ship with auto-fixers.

The recommended configuration also switches on several standard Oxlint rules — no-deprecated, no-require-imports, no-floating-promises, no-unnecessary-condition and no-unreachable — of which several require type-aware linting.

Setup and compatibility

Installation is a single dev dependency, ai-deslop, which pulls in @oxlint/plugins as a runtime dependency; the README warns that this package must stay in sync with your installed oxlint version. The plugin ships as compiled JavaScript and runs on any Oxlint JavaScript-plugin runtime, including Bun, Deno and Node.js. Configuration goes through Oxlint's defineConfig, registering ai-deslop as a JS plugin and applying the recommended preset's options and rules.

Why it matters

As AI assistants take on a growing share of day-to-day coding, the typical failure mode has shifted. Code now tends to compile and look reasonable; what it lacks is substance — casts that assert things the code never proved, types widened into meaninglessness, and tests that pass without testing much of anything. Reviews catch some of this, but human attention does not scale with generated volume.

Linters already sit in the critical path of most CI pipelines, which makes them a cheap enforcement point for exactly this class of problem. Deslop codifies reviewer intuition into automated checks, and its practice of vendoring rules from an existing project like anti-slop suggests a small ecosystem of AI-output policing tools is forming.

The opinions are strong — banning all module mocking or demanding comments on every assertion will be too strict for many teams — but the ruleset is granular enough to adopt selectively. Either way, it is a concrete, runnable answer to a question more teams are asking: how do you keep generated code honest without reading every line yourself?