69e6097b68
Round 8 of the review asked for an AST. That was the right diagnosis of the
wrong problem: the question was never which parser to use, it was why a
test-timeout guard was parsing JavaScript at all.
It got there one reasonable step at a time. The guard enforces two rules no
Vitest config can report — a per-test `retry`, and Testing Library's
`asyncUtilTimeout` — so it read them out of source text, and the review found a
new valid spelling it missed in five consecutive rounds: a trailing comment,
nested parens in `it.each([makeCase()])`, a member-access prefix, the shorthand
`{ retry }`, an aliased import, a non-literal title. Each fix was correct and
each made it more parser-shaped, until it carried eight helpers doing quote
tracking and bracket balancing.
Both rules are observable at runtime, exactly:
- `vitest.setup.shared.mts` is loaded by all six projects and reads
`ctx.task.retry` — the value Vitest resolved for the test. That covers
strictly more than the scan did: a per-test option, a `describe` option
inherited by children, a project-level setting, and a `--retry` flag typed at
a command line, which the scan could never see since it only read npm scripts.
- `clients/web/src/test/asyncUtilTimeout.test.ts` asserts
`getConfig().asyncUtilTimeout`, the value this project's own waitFors read.
Neither has a spelling to anticipate, so neither can be outrun by a new one.
Both were observed firing before being trusted.
The guard keeps only what it can answer by asking Vitest: resolved budgets,
project-level retry, config discovery, and that each project still loads the
setup file — the one thing about the runtime assertion a config CAN report.
868 lines to 361, every scanner helper gone, and 33 of 48 unit tests deleted
because they pinned edge cases of a thing that no longer exists.
storybookSetup.ts goes with it. At the library's own value its configure() call
was a no-op, and the assertion is what pins the number.
AGENTS.md gains the general rule: a rule about what the code DOES is asserted at
runtime, not read out of the source — reach for a verify:* guard when the
question is about configuration, which a tool can be asked to resolve.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PsmUAZ6aLUAFqenjJKSSRp
Signed-off-by: cliffhall <cliff@futurescale.com>
36 lines
1.4 KiB
JSON
36 lines
1.4 KiB
JSON
{
|
|
// Parser project for the ROOT eslint config's type-aware rules (#1959), and
|
|
// nothing else — it emits nothing and gates nothing.
|
|
//
|
|
// `@typescript-eslint/no-floating-promises` needs a program containing the
|
|
// file being linted, and the root scope (`core/**`, `test-servers/src/**`,
|
|
// `vitest.shared.mts`) has no tsconfig of its own: `core/` is typechecked
|
|
// through `clients/web`'s `tsc -b` and `test-servers/src` through
|
|
// `clients/cli`'s test project, neither of which is rooted here. Type
|
|
// *checking* stays where it is; this file only gives the parser a program.
|
|
//
|
|
// `moduleResolution: bundler` because `core/` is written for a bundler
|
|
// (extensionless relative imports) — under NodeNext those fail to resolve,
|
|
// every import degrades to `any`, and the rule silently stops seeing
|
|
// promises at all.
|
|
"extends": "./tsconfig.base.json",
|
|
"compilerOptions": {
|
|
"noEmit": true,
|
|
"module": "ESNext",
|
|
"moduleResolution": "bundler",
|
|
"lib": ["ES2023", "DOM", "DOM.Iterable"],
|
|
"jsx": "react-jsx",
|
|
"types": ["node"],
|
|
"typeRoots": ["./clients/web/node_modules/@types", "./node_modules/@types"]
|
|
},
|
|
"include": [
|
|
"core/**/*.ts",
|
|
"core/**/*.tsx",
|
|
"test-servers/src/**/*.ts",
|
|
"test-servers/src/**/*.tsx",
|
|
"test-servers/src/**/*.mts",
|
|
"test-servers/src/**/*.cts",
|
|
"vitest.shared.mts",
|
|
"vitest.setup.shared.mts"
|
|
]
|
|
}
|