mirror of
https://github.com/4gray/iptvnator.git
synced 2026-10-11 11:06:16 -08:00
4grayandClaude Opus 5
9b7776a901
* chore(lint): hold tests to their own max-lines ceiling The flat 400-line cap treated a spec like a component. A spec is a flat list of independent cases, so hitting the cap there produces arbitrary `-2.spec.ts` splits and hides coverage instead of surfacing design debt — 65 of the 138 files over the limit were tests. Production code keeps 400. Tests (`**/*.spec.ts`, `**/*.e2e.ts`, and everything under `apps/*-e2e/**`) get 1200. Blank lines and comments no longer count, so a docblock can't be the reason a file must be split. Both limits now live in tools/eslint/max-lines-config.mjs, imported by eslint.config.mjs and the baseline generator alike. The generator decides who belongs on the list by running ESLint's own max-lines rule instead of counting lines itself — a private reimplementation would disagree with the rule the moment either side changed (a `//` inside a template literal is enough) and yield a baseline that turns CI red while looking correct. The baseline drops 126 -> 68 entries with nothing added, and six now-dead `eslint-disable max-lines` directives are removed. A new eslint-tools test asserts the committed baseline still matches what the generator produces, so a stale entry or a forgotten regeneration fails CI. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * chore(lint): classify eslint-tools in the coverage policy A project with a `test` target must be assigned a coverage tier, so adding eslint-tools broke `coverage:policy:check` before the unit suite even ran. Tier B alongside packaging and release-tools: these are Node tests over lint tooling, and a coverage percentage across a generated list would not mean anything. CI runs Tier B/C through its own `--run-non-tier-a` step, so the baseline-consistency test executes there rather than being skipped. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
45 lines
1.4 KiB
JavaScript
45 lines
1.4 KiB
JavaScript
/**
|
|
* Single source of truth for the max-lines rule.
|
|
*
|
|
* Both eslint.config.mjs (which enforces the rule) and
|
|
* generate-max-lines-baseline.mjs (which lists the files that predate it) import
|
|
* from here, so the enforced limit and the generated baseline can never drift
|
|
* apart.
|
|
*/
|
|
|
|
/**
|
|
* Production TypeScript. CLAUDE.md asks for under 300 lines; this is the hard
|
|
* ceiling CI enforces.
|
|
*/
|
|
export const MAX_LINES_PROD = 400;
|
|
|
|
/**
|
|
* Tests and test infrastructure. A spec is a flat list of independent cases:
|
|
* splitting one at the production limit yields arbitrary `-2.spec.ts` files and
|
|
* makes coverage harder to find, and a long spec signals thorough coverage
|
|
* rather than the design debt the production limit is meant to catch. The
|
|
* ceiling is still bounded so a runaway fixture gets noticed.
|
|
*/
|
|
export const MAX_LINES_TEST = 1200;
|
|
|
|
/**
|
|
* Comments and blank lines are not counted. This repo mandates documentation
|
|
* (see "Documentation After Changes" in CLAUDE.md), so a docblock must never be
|
|
* the reason a file has to be split.
|
|
*/
|
|
export const MAX_LINES_OPTIONS = {
|
|
skipBlankLines: true,
|
|
skipComments: true,
|
|
};
|
|
|
|
/**
|
|
* Specs, E2E specs, and everything inside the E2E apps — the latter covers
|
|
* fixtures, harnesses and performance capture helpers, which are test
|
|
* infrastructure even though they carry no `.spec`/`.e2e` suffix.
|
|
*/
|
|
export const TEST_FILE_GLOBS = [
|
|
'**/*.spec.ts',
|
|
'**/*.e2e.ts',
|
|
'apps/*-e2e/**/*.ts',
|
|
];
|