strict-unused-vars-lint: Strict unused-variable linting #4
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "task/strict-unused-vars-lint"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Assigned idea
Benchmark authoring specification.
Summary: Tighten yopedia's ESLint flat config so TypeScript unused variables fail linting instead of only warning, while preserving the existing underscore exemptions and ignore globs.
Task intent: Make ordinary upstream maintenance work in the repo by changing the existing @typescript-eslint/no-unused-vars rule in eslint.config.mjs from a warning to an error without altering the Next.js FlatCompat setup or ignored paths.
Benchmark plan: Construct the task package around a single upstream-facing edit to eslint.config.mjs. The prompt should ask the solver to make unused TypeScript variables lint-blocking, preserve argsIgnorePattern and varsIgnorePattern as ^_, and leave the existing ignore list and next/core-web-vitals plus next/typescript extensions intact. Do not require adding dependencies or touching application code.
Environment plan: Task/environment: provide a writable checkout and Python 3 for the verifier; no network access or package installation is needed. Environment/repo: use yologdev/yopedia at bf52a322a082c78be22797b35d1223b746f0f636 with its existing ESLint flat config in eslint.config.mjs; Node tooling is not required for verification.
Verifier plan: Create test_outputs.py that reads eslint.config.mjs and checks deterministic text/structure expectations: the file still imports FlatCompat and extends both next/core-web-vitals and next/typescript; the ignores array still contains node_modules/, .next/, .open-next/, out/, build/, next-env.d.ts, and workers/; the @typescript-eslint/no-unused-vars rule exists exactly as a configured rule with severity "error"; and the rule options retain argsIgnorePattern: "^" and varsIgnorePattern: "^". The verifier should fail if severity remains "warn" or is set to "off".
Oracle plan: The oracle solution is a minimal patch to eslint.config.mjs changing the first element of the @typescript-eslint/no-unused-vars rule tuple from "warn" to "error" while leaving the surrounding FlatCompat setup, ignore globs, and underscore ignore options unchanged.
Difficulty plan: Current coding agents may over-edit a small config file, replace the flat config with legacy ESLint syntax, remove the workers/** ignore entry, drop the underscore exemptions, or add unnecessary package/config changes instead of making the precise severity change.
Repo patch scope: Expected upstream edit scope is only eslint.config.mjs. No application files, package manifests, build artifacts, or other directories should be changed.
Anti-leakage notes: Do not expose solver-facing references to benchmark, harness, Snorkel, Harbor, std-ts, agent, stage, attempt, retry, generated task, or evaluation context.
Approach: Ask for a precise lint policy change: update the existing no-unused-vars severity to error and preserve all established config behavior visible in eslint.config.mjs.
Verification: Run python test_outputs.py from the repository root; it must inspect eslint.config.mjs and pass only when the unused-vars rule is an error with the existing underscore options and ignore globs preserved.
Risk: The main risk is making the verifier too brittle to harmless formatting changes; implement checks with tolerant text matching or simple structural extraction rather than exact whole-file comparison.
Path rules: task package is tasks/; mutable upstream checkout is tasks//environment/repo; benchmark package files are under tasks//task; verifier/container environment belongs under tasks//task/environment; regular and UI verifier logic belongs in task/tests/test_outputs.py and test.sh only runs that file through pytest.
Agent context
Task slug: strict-unused-vars-lint
Branch: task/strict-unused-vars-lint
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.Merge
Merge the changes and update on Forgejo.Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.