---
id: "packages/eslint-config/checks"
title: "Checks and troubleshooting"
description: "When a lint run fails, how to read its result, how to see the rules ESLint applies, and what common messages mean."
url: "/packages/eslint-config/checks"
locale: "en"
revision: "ac4d2148579a6e18"
---

# Checks and troubleshooting

## When a lint run fails

ESLint reports every finding as a warning (see [the overview](/packages/eslint-config)). Whether a
run fails is decided by the threshold in your `lint` script:

| Result of `eslint . --max-warnings 100` | Exit code | Message |
| --- | --- | --- |
| no findings | 0 | none |
| 1 to 100 warnings | 0 | `✖ 100 problems (0 errors, 100 warnings)` |
| 101 warnings or more | 1 | `ESLint found too many warnings (maximum: 100).` |
| a file that does not parse | 1 | `error  Parsing error: …` |
| a configuration that cannot be loaded (a missing package) | 2 | `Oops! Something went wrong! :(` |

Read the summary line of every run, not only the exit code. To see whether your own work added
warnings, run with a lower threshold for yourself:

```bash
pnpm exec eslint . --max-warnings 0
```

## Thresholds and repository scripts

The threshold belongs to your repository, not to the package:

- **Per package.** Each `lint` script carries `--max-warnings 100`, the shared standard. Do not
  raise it for one package to get a run through.
- **Across the repository.** A root script runs lint in every workspace, for example
  `turbo lint --continue` or `pnpm -r --no-bail lint`. Without "continue" or "no bail", the run
  stops at the first workspace that fails and hides the others. The root run fails when any
  workspace fails.
- **Further checks.** A repository may have its own checks or a finishing command that read the
  lint result. They are policy of that repository and are named in its own `AGENTS.md`; the
  package has none.

## See which rules apply

Print the configuration ESLint computes for one file:

```bash
pnpm exec eslint --print-config src/index.ts
```

The output lists every rule with its configured severity: `2` for error, `1` for warning, `0` for
off. A rule configured as `2` is still **reported** as a warning, because `only-warn` changes the
severity when a finding is reported, not in the configuration. So `--print-config` tells you which
rules run and with which options, not whether a run fails.

To see which preset each workspace imports:

```bash
grep -rhoE "eslint-config/(base|react-internal|next-js|resource-rules)" --include=eslint.config.mjs apps packages | sort | uniq -c
```

## Check your copy

| Question | Command |
| --- | --- |
| which version and source state does my repository record? | `node tools/rps/rps-apply.mjs status` |
| does my repository resolve the managed copy? | `node tools/rps/rps-apply.mjs verify-install --from .` |
| does my copy match a bundle, file by file? | `node tools/rps/rps-apply.mjs reconcile --bundle <bundle-folder>` |

## Common messages

| Message | Cause and remedy |
| --- | --- |
| `Cannot find package '@workspace/eslint-config'` | the package is not declared at the root or not installed: declare it, run `pnpm install` |
| `Package subpath './…' is not defined by "exports"` | an import path that is not one of the four subpaths; see [Presets](/packages/eslint-config/presets) |
| `… is not listed as a dependency in turbo.json` | an environment variable that `turbo.json` does not declare, or a repository without Turbo; see [Local additions](/packages/eslint-config/local-additions#environment-variables-without-turbo) |
| `Em-dash (—, U+2014) is banned in user-visible text` | text in JSX with an em-dash; use `-`, `:`, `.` or a parenthesis. Strings outside JSX are not checked |
| `Use 'err' instead of 'e' for catch variables` | rename the `catch` binding to `err`, or `xxxErr` in a nested catch |
| `RPS-E4` or `RPS-E5` from the applier | a changed managed file, or an unmanaged folder at `packages/eslint-config`; see [Getting started](/packages/eslint-config/getting-started#an-existing-repository) |

The convention messages name `I18N_STANDARDS.md § 3` and `CODING_STANDARDS § 4`. Those are
documents of the development standards, in `docs/standards/` of a repository that took them over.
The message for `catch (error)` also mentions `@workspace/active-logging`, a package of the
repository where the convention arose; the rule works the same without it.