Current behavior
A custom job without target_pattern errors out when run via plur spec:
[job.lint]
cmd = ["rubocop"]
$ plur --use=lint
ERROR - job "lint" has no target_pattern and framework "passthrough" has no detect patterns
This happens because SpecCmd.Run always goes through file discovery (FindFilesFromJob) before running anything. If there's no target_pattern and the framework has no detect patterns, it fails.
The same issue affects known frameworks. A job like cmd = ["bin/rspec"] (no {{target}} placeholder) should just run bin/rspec — rspec knows its own scope. But plur still requires file discovery to succeed.
Jobs that work in watch mode (like [job.build] with cmd = ["bin/rake", "install"]) fail through plur spec --use=build because watch bypasses the file-discovery path but spec doesn't.
Expected behavior
Running a job should work the same way any CLI invocation works. If you define cmd = ["rubocop"], plur should just run rubocop. If you pass file arguments (plur spec/foo_spec.rb), they get forwarded. If you don't, the command runs as-is.
Broader design question: remove target_pattern from user config
target_pattern exists mainly to support autodetection of rspec vs minitest — an internal convenience for Ruby test suites. It shouldn't need to be a user-facing config concept.
In a perfect world:
target_pattern becomes purely internal (used by autodetect logic, not exposed in .plur.toml)- A job is just
cmd + optional framework
- File arguments come from CLI args, not from plur scanning the filesystem
- If no files are passed, the command runs with no file args — same as invoking it directly
This would simplify the config surface and eliminate a whole class of "why doesn't my job work" confusion.
Related
- The
{{target}} placeholder in commands is the mechanism for plur to inject discovered files. Jobs without {{target}} in their cmd don't need file discovery at all — they should just run.
- Watch mode already handles this correctly for its jobs.
Current behavior
A custom job without
target_patternerrors out when run viaplur spec:This happens because
SpecCmd.Runalways goes through file discovery (FindFilesFromJob) before running anything. If there's notarget_patternand the framework has no detect patterns, it fails.The same issue affects known frameworks. A job like
cmd = ["bin/rspec"](no{{target}}placeholder) should just runbin/rspec— rspec knows its own scope. But plur still requires file discovery to succeed.Jobs that work in watch mode (like
[job.build]withcmd = ["bin/rake", "install"]) fail throughplur spec --use=buildbecause watch bypasses the file-discovery path but spec doesn't.Expected behavior
Running a job should work the same way any CLI invocation works. If you define
cmd = ["rubocop"], plur should just runrubocop. If you pass file arguments (plur spec/foo_spec.rb), they get forwarded. If you don't, the command runs as-is.Broader design question: remove
target_patternfrom user configtarget_patternexists mainly to support autodetection of rspec vs minitest — an internal convenience for Ruby test suites. It shouldn't need to be a user-facing config concept.In a perfect world:
target_patternbecomes purely internal (used by autodetect logic, not exposed in.plur.toml)cmd+ optionalframeworkThis would simplify the config surface and eliminate a whole class of "why doesn't my job work" confusion.
Related
{{target}}placeholder in commands is the mechanism for plur to inject discovered files. Jobs without{{target}}in their cmd don't need file discovery at all — they should just run.