Skip to content

Move TBD scan config into paths, shared by check:tbd and replace-tbd #56

@jonwaldstein

Description

@jonwaldstein

Summary

The directories (and skip rules) used to scan for TBD placeholders currently live under checks.tbd (dirs, skip_files, skip_directories). Both check:tbd and the new replace-tbd command read them from there.

This works and keeps the two commands in sync, but it's conceptually inconsistent with how version files are configured: paths.versions is shared config that check:version-conflict, get-version, package, and replace-version all read. By that model, "which directories hold my source" feels like a project-level paths concern, not a check-specific one.

Proposal

Introduce a paths-level config for the TBD scan scope (e.g. paths.tbd or a more general source-dirs key) and have both check:tbd and replace-tbd read it, so they stay in lockstep.

  • Add the new paths key (with dirs / skip_files / skip_directories, or whatever shape we settle on) to .puprc-defaults.
  • Update Check\TbdScanner / its callers to source config from paths first.
  • Backcompat: fall back to checks.tbd.{dirs,skip_files,skip_directories} when the new paths key isn't present, so existing .puprc files keep working. Consider a deprecation notice when the old location is used.
  • Update docs (docs/commands.md, docs/configuration.md, docs/checks.md) and tests.

Constraints / non-goals

  • Both commands must read the same source. The hard requirement is that check:tbd and replace-tbd never diverge on which files they consider — that's the whole point of replace-tbd being the check's companion. Whatever we do, do it for both, not one.
  • Do not split the config (e.g. replace-tbd on paths while check:tbd stays on checks.tbd) — that silently breaks the parity contract.

Context

Came out of review discussion on #55. For that PR we intentionally kept checks.tbd to preserve parity with the existing check at zero backcompat risk; this issue tracks the cleaner config model as a separate, backcompat-sensitive change.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions