anti-slop README

The project's README from github.com/dmmulroy/anti-slop. As one markdown file: README.md.

anti-slop

skills.sh

Opinionated Oxlint rules that reject low-evidence and low-signal TypeScript and JavaScript patterns.

Anti-slop is first and foremost the ruleset I use with my work, projects, and team. It reflects my preferences and taste rather than attempting to be a universal coding standard.

This project is meant to be vendored, not treated as a fixed npm dependency. There is no official npm package. Copy the rules into your repository, read them, and change them to match your team's standards. The bundled agent skill handles the initial copy and configuration; after that, the vendored files are yours to maintain and make your own. Community-maintained forks and packages are welcome, but their compatibility and release lifecycle belong to their maintainers.

Install with an agent skill

npx skills add dmmulroy/anti-slop --skill install-anti-slop

Then ask your coding agent to install or configure anti-slop in the current repository. The skill copies the plugin, installs compatible Oxlint dependencies—matching an existing Oxlint version when present—merges the plugin into the existing lint configuration, enables every generic rule, and validates the result. In repositories that depend directly on Effect, it also enables the opt-in Effect rule group.

Update an existing installation

Ask your agent to update anti-slop while preserving local customizations, optionally naming an upstream revision or selected fixes. The same skill stages incoming source separately, uses a three-way merge when the original upstream snapshot is recoverable, and otherwise ports reviewed changes conservatively. It preserves local rules and configuration, asks about conflicting policy and enabling new rules, and records provenance for future updates. It does not force-replace the vendored directory.

For latest upstream, ask the agent to retrieve and identify that revision; an already-installed skill bundle may be older. The copy script itself does not fetch or merge updates.

To inspect available skills first:

npx skills add dmmulroy/anti-slop --list

Manual local installation

Copy src/ into the target repository, for example at tools/oxlint/anti-slop/. If the repository already uses oxlint, install @oxlint/plugins at exactly the resolved Oxlint version. Otherwise, install the same current version of both packages. Keep both versions exact so upgrades move them together.

Register the copied entry point in oxlint.config.ts:

import { defineConfig } from "oxlint";

export default defineConfig({
  ignorePatterns: [
    ".agent/**",
    ".agents/**",
    ".claude/**",
    ".codex/**",
    ".continue/**",
    ".cursor/**",
    ".gemini/**",
    ".opencode/**",
    ".pi/**",
    ".roo/**",
    ".windsurf/**",
    "tools/oxlint/anti-slop/**",
  ],
  jsPlugins: [
    { name: "anti-slop", specifier: "./tools/oxlint/anti-slop/index.ts" },
  ],
  rules: {
    "oxc/no-accumulating-spread": "error",
    "anti-slop/no-array-filter-map": "error",
    "anti-slop/no-reduce-accumulator-copy": "error",
    "anti-slop/no-chained-type-assertions": "error",
    "anti-slop/no-conditional-empty-object-spread": "error",
    "anti-slop/no-known-value-widening": "error",
    "anti-slop/no-module-mocking": "error",
    "anti-slop/no-object-parameters": "error",
    "anti-slop/no-reflect-apply": "error",
    "anti-slop/no-reflect-get": "error",
    "anti-slop/no-runtime-typeof": "error",
    "anti-slop/no-shape-in-symbol-names": "error",
    "anti-slop/no-unknown-parameters": "error",
    "anti-slop/no-unknown-returns": "error",
    "anti-slop/no-unknown-type-aliases": "error",
    "anti-slop/no-unsafe-dictionary-type": "error",
    "anti-slop/no-widen-then-assert": "error",
    "anti-slop/require-safety-comment-for-type-assertion": "error"
  }
});

The same ignorePatterns, jsPlugins, and rules work under lint in a Vite+ config. Merge the ignore patterns into Vite+'s fmt.ignorePatterns as well so vp check does not reformat installed agent assets or the vendored plugin. Preserve existing ignores and add any other project-local agent tooling directories detected in the repository; do not broadly ignore every dot-directory.

Optional Effect rules

Effect-specific rules live in a separate plugin so projects that do not use Effect do not inherit Effect architecture policy. Register the Effect entry point only in repositories that use Effect:

export default defineConfig({
  jsPlugins: [
    { name: "anti-slop", specifier: "./tools/oxlint/anti-slop/index.ts" },
    {
      name: "anti-slop-effect",
      specifier: "./tools/oxlint/anti-slop/effect/index.ts"
    }
  ],
  rules: {
    "anti-slop-effect/no-service-constructor-imports": "error"
  }
});

Rules

Generic rules

Effect rules

Analysis boundaries

The rules use Oxlint's ESTree and lexical-scope APIs rather than a TypeScript type checker. They resolve same-file aliases—including block-scoped aliases, forward references, and transparent generic aliases—but do not infer imported type definitions or cross-file call signatures. Rules that inspect calls therefore document when enforcement is intentionally local.

Violation examples

Each snippet below is rejected by the named rule.

no-array-filter-map

const users: User[] = loadUsers();
const emails = users.filter(user => user.active).map(user => user.email);
const found = users.map(lookup).filter(value => value !== undefined);

Prefer lazy iterator helpers where the target runtime supports them:

const emails = users.values()
  .filter(user => user.active)
  .map(user => user.email)
  .toArray();

A single flatMap(user => user.active ? [user.email] : []) or a reducer that pushes into a fresh local array is also allowed. Iterator helpers avoid intermediate arrays and per-item wrapper arrays, but are not guaranteed to be faster. Check runtime support; TypeScript library declarations do not polyfill them.

This AST/scope rule recognizes array literals, direct array/tuple annotations, immutable local aliases, and supported array-preserving method chains. Unknown receivers (including imported factory results and unannotated parameters), type aliases, and property-based array types are not inferred. Iterator pipelines are not flagged. Both filter().map() and map().filter() are covered, regardless of predicate. There is no autofix: callback ordering, indexes, thisArg, sparse arrays, and truthiness filtering must be reviewed before changing APIs.

no-reduce-accumulator-copy

items.reduce((acc, item) => Object.assign({}, acc, { [item.id]: item }), {});
items.reduce((acc, item) => acc.concat([item]), []);
items.reduce((acc, item) => {
  const next = acc.slice();
  next.push(item);
  return next;
}, []);

Instead, mutate a fresh, locally owned accumulator and return it:

items.reduce((acc, item) => {
  acc.push(item);
  return acc;
}, []);

Object.assign(acc, item) is also allowed. Copying individual input items is not copying accumulated state.

The rule covers inline reduce/reduceRight callbacks, including index parameters, and immutable local accumulator aliases. It detects global Object.assign with an object-literal target and the accumulator as a source, global Array.from(acc), and array accumulator calls to concat, slice, toSpliced, toSorted, toReversed, and with. Array copy methods require local array evidence for the initial value so string concatenation and unknown custom collections are not flagged. Like the native rule, reducer method names are syntactic evidence, not proof of the receiver's runtime type. Named callbacks, nested functions, indirect copy helpers, nested accumulator properties, and reassigned aliases are outside its scope. Copying a bounded accumulator is not necessarily quadratic, but these patterns are rejected because growing accumulators can be.

Enable native oxc/no-accumulating-spread alongside it for array/object spreads in reducers and supported loops. Neither rule proves that every possible quadratic reduction is absent. No automatic mutation rewrite is provided because accumulator ownership cannot be established syntactically.

no-chained-type-assertions

const user = input as object as User;

no-conditional-empty-object-spread

const options = {
  ...(timeout !== undefined ? { timeout } : {}),
};

no-known-value-widening

const handlers: Record<string, Handler> = {
  start: startHandler,
};

This discards the known start key. Preserve inference or use satisfies Record<string, Handler> instead.

Known values must not be widened back to unknown through a local type predicate:

function isUser(value: unknown): value is User {
  return UserSchema.safeParse(value).success;
}

declare const user: User;
isUser(user);

Call the predicate at the unparsed boundary, while the argument is still unknown.

no-module-mocking

vi.mock("./user-store");

no-object-parameters

function save(value: object) {}

no-reflect-apply

const value = Reflect.apply(operation, owner, args);

no-reflect-get

const value = Reflect.get(owner, key);

no-runtime-typeof

if (typeof input === "string") {
  useName(input);
}

Schema-free projects can permit typeof checks directly inside type predicate and assertion functions while continuing to reject ad hoc checks elsewhere:

{
  "anti-slop/no-runtime-typeof": [
    "error",
    { "allowInTypeGuards": true }
  ]
}

The option defaults to false. Existence probes such as typeof document === "undefined" are always allowed because they establish whether a binding exists rather than narrow its representation.

no-shape-in-symbol-names

interface UserShape {
  id: string;
}

Static member reads such as schema.shape are allowed because the member name belongs to the value's owner and cannot be renamed locally.

Effect: no-service-constructor-imports

import { makeIssueService } from "./issue-service.ts";

Import the owning Layer and yield IssueService instead. Focused *.test.* and *.spec.* files may import the constructor directly.

no-unknown-parameters

function handle(input: unknown) {}

A type predicate may accept unknown for the parameter it narrows; other unknown parameters on the same function remain rejected.

no-unknown-returns

function loadUser(): unknown {
  return input;
}

no-unknown-type-aliases

type ExternalValue = unknown;

no-unsafe-dictionary-type

type Metadata = Record<string, unknown>;
type OtherMetadata = { [key: string]: object };

no-widen-then-assert

const loaded: User = loadUser();
const stored: unknown = loaded;
const user = stored as User;

require-safety-comment-for-type-assertion

const userId = value as UserId;

Add a specific justification immediately before a necessary assertion:

// SAFETY: parseUserId validated the identifier before branding it.
const userId = value as UserId;

SAFETY remains the default marker. Comments immediately above exported declarations are recognized. Repositories with an established convention can configure one or more alternatives; every marker must still be followed by a colon and a non-empty justification:

{
  "anti-slop/require-safety-comment-for-type-assertion": [
    "error",
    { "markers": ["INVARIANT", "SAFETY"] }
  ]
}

Development

pnpm install
pnpm check

src/ is canonical. After changing production source, run pnpm sync:skill-assets; CI checks that the skill's bundled copy remains identical. pnpm check runs Oxlint, every RuleTester suite, TypeScript typechecking, and the skill-asset drift check.

License

MIT

anti-slop (dmmulroy/anti-slop)

Searching Database…

What is this?A set of opinionated Oxlint rules that reject low-evidence and low-signal patterns in TypeScript and JavaScript codebases.
Is it an npm package I add as a dependency?No — there is no official npm package. Anti-slop is meant to be vendored: you copy the rules into your repository, read them, and maintain them as your own.
How do I get it into my repository?Ask your coding agent to install anti-slop: the bundled skill copies the plugin, installs matching Oxlint dependencies, merges it into your lint config and validates the result. Manually, copy src/ into your repo (e.g. tools/oxlint/anti-slop/) and register the entry point in oxlint.config.ts.
Do I need Oxlint installed first?Yes — it is an Oxlint plugin, so you need oxlint plus @oxlint/plugins, both pinned to exactly the same version so upgrades move together; an existing Oxlint version is matched when present.
How deep does the analysis go — will it catch every bad pattern?No. The rules run on Oxlint's ESTree and lexical-scope APIs, not a TypeScript type checker: they resolve same-file aliases but do not infer imported types or cross-file call signatures, so enforcement is intentionally local.
Is this meant to be a universal standard for every team?No — it is the author's personal ruleset reflecting his own taste; the idea is that you read the vendored rules and change them to match your team's standards.
What kinds of patterns do the rules actually reject?Seventeen generic rules flag things like eager filter-then-map chains, chained type assertions, object parameters, unknown-typed contracts, and Vitest or Jest module mocking; one rule requires a SAFETY comment justifying every non-const type assertion. Repositories using Effect can enable an extra opt-in rule group, e.g. no-service-constructor-imports.
How do I update my vendored copy when upstream changes?Ask your agent to update anti-slop: the skill stages incoming source, uses a three-way merge when the upstream snapshot is recoverable, preserves your local rules and configuration, and records provenance instead of force-replacing the directory.
Do the rules come with autofixes?Mostly no. Several rules intentionally ship without autofix — e.g. conditional empty-object spreads and filter-then-map rewrites need human review — so plan to fix reported violations yourself.
Does it work in a Vite+ setup?Yes — the same ignorePatterns, jsPlugins and rules work under Vite+ lint, and you should merge the ignore patterns into Vite+'s fmt.ignorePatterns so vp check does not reformat the vendored plugin or agent assets.
Creator
dmmulroy
Size
0.1 MB
Stars
5.6K
Updated
CommitOct 14
Age
2mo
Commits · 90 Days