exclude: array in your config, and CLI flags for ad-hoc runs. You can mix all three — aislop merges them before scanning. For silencing a specific finding on a single line rather than excluding a whole file, see Rule Overrides → Inline suppressions.
Default exclusions
The following paths are excluded automatically on every scan, regardless of your config:exclude: list and apply even when no config file is present.
Method 1: .aislopignore
Create a.aislopignore file at the project root. It uses the same glob syntax as .gitignore and supports # comments.
.aislopignore is the right choice when you want exclusions tracked in version control and shared with everyone who runs aislop on the project, without coupling them to the config file.
Method 2: exclude in config.yml
Add anexclude: array to .aislop/config.yml. Every entry is a glob pattern. This is the right choice when your exclusions are tightly coupled to your config — for example, when a strict config excludes test files and a relaxed config does not.
Restricting to specific paths
Useinclude: to limit scanning to a subset of your project. aislop only scans files that match at least one include: pattern and do not match any exclude: pattern. An empty include: (the default) scans everything not excluded.
Method 3: CLI flags
Pass--exclude or --include directly to aislop scan or aislop ci for a one-off run without changing your config. Both flags accept comma-separated glob patterns.
exclude: and .aislopignore — they do not replace them.
Common exclusion patterns
Generated code
Generated code
Generated files contain patterns that look like slop (generic names, narrative comments, unsafe casts) but are intentional outputs of a code generator. Exclude them so they don’t distort your score.
Test snapshots
Test snapshots
Snapshot files are large, auto-generated, and contain no logic worth analysing. Exclude them by file extension.
Legacy or vendored directories
Legacy or vendored directories
When adopting aislop incrementally in a large codebase, exclude legacy code until you’re ready to address it. Track the exclusions in
.aislopignore so you can remove them one directory at a time.Test and fixture files
Test and fixture files
Some teams prefer to exclude test files from scoring so that only production code contributes to the score. Use
config.yml for this so the exclusion is part of your versioned configuration.Monorepo: per-package exclusions
Monorepo: per-package exclusions
In a monorepo, each package can have its own
.aislop/config.yml that extends a root base config. Set exclude: in the child config to add package-specific exclusions — but remember that arrays are replaced, not merged, so repeat the defaults you want to keep.Summary: which method to use
| Method | Best for |
|---|---|
.aislopignore | Exclusions shared across the whole team, decoupled from config |
exclude: in config | Exclusions that vary between config profiles (strict vs. relaxed) |
--exclude / --include CLI flags | Ad-hoc one-off runs without touching committed files |