feat(cli): add qawolf flows lint to check flow files against QA Wolf's rules - #1537
feat(cli): add qawolf flows lint to check flow files against QA Wolf's rules#1537Jason Allen (JAllen2022) wants to merge 5 commits into
Conversation
|
Important Draft PR not reviewedDraft PRs are not automatically reviewed by default.
To automatically review draft PRs, update your CodeRabbit configuration: reviews:
auto_review:
drafts: trueComment |
Jason Allen (JAllen2022)
changed the title
Five problems, all in the path a bare `qawolf flows lint` takes: Generated output was linted. Without a pattern the command selects every source file in the project, and only node_modules was excluded, so a repo that builds to dist/ failed the gate on its own compiled output. The team config search could escape the project. It stopped at the package root, but that is unknown whenever the selected files span more than one package, which is every monorepo. The walk then ran to the filesystem root and could read a stray .eslintrc.json from the user's home directory. Every file was linted at once, each building its own TypeScript program and its own linter. The linter is the same for all of them and the repo already has a bounded-concurrency helper. An unreadable file took the whole run down with a stack trace and no report. It is now named in the output and fails the gate, because a gate that passes files it never checked is worse than one that stops. The lint domain reached into the flows domain, which the architecture forbids and nothing caught: the boundary rules are listed per domain by hand and lint was never added.
b2bd56d to
5493d4b
Compare
The fixes pushed both the module and its test past the line limits oxlint enforces, so file selection and the team config lookup each move out on their own. Also reformats the lint config the fixes edited, which was not written the way oxfmt writes it.
|
Closed in favour of qawolf/platform#31630, which solves NOVA-1586 without publishing anything. The lint gate Tester actually needs already shipped: That covers Tester and the session console without publishing The gap it leaves is customers linting on their own laptops or in CI, which nothing covers today. Worth its own ticket if that turns out to be wanted. |
|
Reopened. The earlier close was reversed — this is the route we're taking after all. The reasoning is on qawolf/platform#31630, which is now closed in favour of this: Tester's capabilities are moving onto Still blocked on qawolf/platform#32443 for the published |
| | `qawolf environment update` | write | Update an environment owned by the caller's team and return it in the environment.get shape. Omitted fields remain unchanged. | | ||
| | `qawolf flow addTag` | write | Assign an existing tag to the selected flows. Create tags with tag.create. | | ||
| | `qawolf flow update` | write | Move a flow between draft and active readiness. The other statuses shown in the app are derived and cannot be set. | | ||
| | `qawolf flows lint` | local | Lint source files matching [pattern], or every .ts/.js file when omitted, with QA Wolf's rules, honoring the project's .eslintrc.json | |
There was a problem hiding this comment.
Does this belong on the flows namespace?
There was a problem hiding this comment.
I am not even sure if we need this, if we publish our own rules and add them to the .eslintrc.json as a package, users can use eslint command directly instead of going throught our cli
3 participants
Overview of Changes
qawolf flows lint [pattern]lints source files with QA Wolf's own rules - the same linter the platform editor and Tester run, imported from@qawolf/workflow-linter. It sits in theflowsgroup besidelist,pull, andrun, and expands patterns through the sameexpandPatternshelper (node_modulesexcluded,.qawolf/<env>/caches included). No pattern means every.ts/.jsfile in the project - flows, helpers, and page objects alike, since the POM rules a team's.eslintrc.jsonenables target exactly the non-flow files. The lint domain owns lintability: patterns select candidates, andselectLintableFileskeeps.ts/.js(same extension test as the platform'slintFilePath), so a pattern matching a.jsonnever gets parsed as TypeScript. It reads the project's.eslintrc.json(severity-only overrides, bundled plugins only, same contract as the editor) by walking up from cwd, bounded by the package root viaresolveProjectDirSafe. Output is eslint-stylish per file plus a problem count. Type-aware rules work - the command builds a real TS program over each file's import graph, so things likeno-unnecessary-type-assertionfire across files.Exit codes: 0 for clean or warnings-only,
testFailure(1) when any error-level finding exists,invalidArgs(2) when a pattern matches no lintable file - including a pattern that matches only non-lintable files, which would otherwise pass a gate it never checked. Zero matches followsflows run, notflows list- the two siblings disagree, and lint is a CI gate like run: a typo'd pattern silently passing is the failure worth catching.--allow-no-matchdowngrades it to 0, same flag as run. Mixed matches lint the lintable subset silently, like eslint.Registered as a
localcommand (no auth, no API), so the generated skill table advertises it to agents as safe to run and retry. Minor changeset included.Testing
bun run typecheck bun run lint bun run format:check bun run knip bun test bun run generate1874 tests pass, 18 of them lint's. Also verified end to end with the built bundle (
node dist/cli.js) in a temp project: a bare run reports the flows, a helper, and asrc/pages/page object while.json/.mdfiles never appear; a pattern narrows; a.json-only pattern is a no-match (exit 2 with the--allow-no-matchhint, 0 with the flag);.eslintrc.jsondowngrading a rule to warn turns all findings into warnings + exit 0; cross-file type-aware findings fire; and a parent directory's.eslintrc.jsonoutside the project is ignored.Checklist