Checks and troubleshooting
When a lint run fails, how to read its result, how to see the rules ESLint applies, and what common messages mean.
@workspace/eslint-config 2.2.0Developmentunreleased, in development in Foundationbaseline ce081dc3
When a lint run fails#
ESLint reports every finding as a warning (see the overview). Whether a
run fails is decided by the threshold in your lint script:
Result of eslint . --max- | 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:
pnpm exec eslint . --max-warnings 0Thresholds and repository scripts#
The threshold belongs to your repository, not to the package:
- Per package. Each
lintscript 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 --continueorpnpm -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:
pnpm exec eslint --print-config src/index.tsThe 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:
grep -rhoE "eslint-config/(base|react-internal|next-js|resource-rules)" --include=eslint.config.mjs apps packages | sort | uniq -cCheck your copy#
| Question | Command |
|---|---|
| which version and source state does my repository record? | node tools/ |
| does my repository resolve the managed copy? | node tools/ |
| does my copy match a bundle, file by file? | node tools/ |
Common messages#
| Message | Cause and remedy |
|---|---|
Cannot find package '@workspace/ | the package is not declared at the root or not installed: declare it, run pnpm install |
Package subpath './ | an import path that is not one of the four subpaths; see Presets |
… is not listed as a dependency in turbo. | an environment variable that turbo. does not declare, or a repository without Turbo; see Local additions |
Em- | 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 xxx in a nested catch |
RPS- or RPS- from the applier | a changed managed file, or an unmanaged folder at packages/; see Getting started |
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.