Local additions
Where your repository adds its own ignores and rules, what the shared standard allows, and how a local rule reports.
@workspace/eslint-config 2.2.0Developmentunreleased, in development in Foundationbaseline ce081dc3
A preset is the shared baseline. What only your repository needs goes in your own
eslint., after the preset, never in the package copy. A change to the package copy is a
defect: the next transfer stops on it.
A trailing block#
Spread the preset first, then add your ignores and rules in blocks after it. A later block wins over an earlier one:
// eslint.config.mjsimport {config} from '@workspace/eslint-config/base';
/** @type {import("eslint").Linter.Config[]} */export default [ ...config, { ignores: ['node_modules/**', 'dist/**', 'coverage/**'], }, // This service writes to its log, never to the console. { files: ['src/**/*.ts'], rules: { 'no-console': 'error', }, },];A local rule reports a warning too#
only- applies to your blocks as well. The 'error' above is reported as a warning:
4:5 warning Unexpected console statement no-console
✖ 1 problem (0 errors, 1 warning)A local rule therefore never fails a run on its own; it counts towards the threshold like every other warning. The package offers no way to make one rule fail a run by itself. If your repository needs that, it is a check of its own, outside this configuration.
What the shared standard allows#
The development standard (docs/ § 3 in your copy of the standards)
sets the limits. In short:
| Allowed | Not allowed |
|---|---|
your own ignores | switching off the em-dash or the catch-naming convention |
| stricter rules, in a trailing block | disabling only- |
| rules for your own tools, in a trailing block | raising the threshold of one package above 100 |
| a narrow, scoped exception with its reason | editing the package copy |
An exception to these limits is a decision your repository records in its own
docs/, never a silent local variant. A rule that would serve every repository is
proposed to the maintainer of Foundation instead.
The package's own reference lists common additions (docs/, section Consumer-side rule
additions, in your copy) and two more limits: do not switch the convention rules off per
repository, and do not re-enable an @eslint- hooks rule, because eslint-
is the one hooks authority and a second rule reports the same finding twice.
One exception in the code#
For a single, deliberate exception, disable the rule on the line, with the reason after --:
// eslint-disable-next-line @typescript-eslint/no-explicit-any -- the plugin API is untypedexport function register(plugin: any): void {The reason names what makes this case different, not "intentional" or "false positive". In order of preference: fix the code, correct the configuration, a scoped override, and only then a line exception. Never switch a rule off everywhere for one case.
Environment variables without Turbo#
turbo/ reports every environment variable a file reads that turbo.
does not declare. In a repository with Turbo, declare the variable in turbo..
A repository without a turbo. gets a warning for every variable a file reads:
4:17 warning API_TOKEN is not listed as a dependency in turbo.json turbo/no-undeclared-env-varsThe shared standard does not yet say how such a repository handles the rule. Until it does, these warnings count towards your threshold, and switching the rule off, even for some files, is a decision your repository records with its reason.