@kaisers-io/refs 0.13.1 → 0.14.1

package/CHANGELOG.md

@@ -5,6 +5,100 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [0.14.1] - 2026-09-13
+
+### Fixed
+
+- **A symlink with no package behind it no longer makes the scan unreliable.** A symlinked
+  directory can never be walked — `readdir` uses lstat semantics — so one that could have held a
+  package was reported as an uninspected candidate, and a single one of those turns the
+  unregistered-package pass off for the whole ref. `withastro/astro` carries two fixture links
+  whose targets hold markdown and JSON and no manifest at any depth: its scan reported two
+  obstacles and stood discovery down permanently, over directories where there was nothing to
+  find.
+
+  The question is now answered by LOOKING rather than by reasoning about the pattern: is there a
+  `package.json` anywhere below the link's target? If there is not, no pattern selects a package
+  there and the link hid nothing from anyone. If there is one — at any depth — it is reported
+  exactly as before. The search spends the scan's own budget and reports the obstacle when it runs
+  out, because an unfinished look is not a look.
+
+  An earlier attempt tried to prove instead that the target's own path selects whatever the link
+  path selects. It cannot be proven from the pattern's shape: a pattern selecting by position, an
+  exclusion naming the target or one of its descendants, a pattern matching the alias but not the
+  real path, and a link pointing at the base all break it in different ways. Each of those five
+  keeps being reported.
+
+## [0.14.0] - 2026-09-13
+
+### Upgrading
+
+**A repository declaring a workspace pattern like `packages/**` now reports every member behind
+it.** Those patterns were refused outright, which also stood the unregistered-package pass down for
+the whole ref — so a ref that reported nothing for months may suddenly name hundreds of packages.
+They are not new; they were invisible. `refs doctor` prints the first ten and a count of the rest,
+`refs doctor --json` carries all of them, and
+`refs edit --package=<name> --decline --path=<path> <ref>` records the ones you do not want so they
+stop coming back.
+
+### Added
+
+- **A workspace pattern that matches at more than one depth is expanded.** `packages/**/*` — the
+  most common pnpm spelling — was reported as `unsupported_pattern`, which also made the whole scan
+  unreliable and stood the unregistered-package pass down for that ref. A repository declaring it
+  got no answer at all, permanently.
+
+  Such a pattern is now walked from the deepest directory it names outright. Pruning is the
+  MATCHER's decision: minimatch answers "could anything below this directory still match?", so a
+  subtree no pattern can reach is never entered, a hidden directory is skipped where a wildcard
+  would not select it and walked where a pattern names it, and a package boundary does not stop
+  the walk — nested packages are ordinary, and both resolvers glob manifest paths rather than
+  stopping at one. Selection matches the manifest path for the same reason: `packages/core/**`
+  selects `packages/core` itself, because `**` matches zero segments before the manifest.
+  `node_modules` and `.git` are never walked under any pattern — a recursive pattern matches an
+  installed dependency's path as a string, and reporting those would be reporting a repository's
+  dependencies as its own packages.
+
+  The whole scan runs under one budget shared by every pattern — 32 levels deep, 20 000
+  directories, 200 000 entries — because patterns overlap, and a per-pattern budget would charge
+  the same tree once per declaration. Reaching a limit is not itself a failure; having to leave a
+  subtree that could still match unwalked is, and that is the only condition `scan_budget_exhausted`
+  is reported under. A directory the pattern names but the repository does not have stays silent,
+  which is ordinary: astro declares `smoke/**/*` and a fresh clone has no `smoke/`.
+
+  Measured against the resolvers themselves, on fresh clones: `withastro/astro` now detects 554
+  packages where pnpm's own workspace listing reports 554 and refs previously reported 37;
+  `vercel/next.js` detects 38 where pnpm reports 38; `payloadcms/payload` 53 where pnpm reports 53.
+  Pattern semantics were checked against `@npmcli/map-workspaces` over six pattern shapes.
+
+- **A ref with hundreds of findings no longer prints all of them.** The same repositories that
+  motivated the expansion can legitimately have hundreds of workspace members, so a ref tracking
+  three of them would print 551 repair commands into one `doctor` line. Ten are printed, followed
+  by a count of what was held back — act on those and run the check again for the next batch.
+  `refs doctor --json` carries every finding on the check itself, uncapped: a finding no command
+  can repair is never cleared by acting on the ones printed before it, so a capped list would put
+  it permanently out of reach.
+
+- **A drift finding you have decided against can be recorded, so it stops coming back.**
+  `refs doctor` reports every workspace member a checkout declares that the configuration does not
+  have. There was no way to say "I looked, and no": the finding returned on every run forever, so
+  `config-drift` sat on `warn` permanently and the next real finding arrived in a line already
+  being ignored. On a home tracking four monorepos, six of seven findings were decisions that had
+  already been made — a repository root, and four packages published nowhere.
+
+  `refs edit --package=<name> --decline --path=<path> <ref>` records the decision on the ref, as
+  the name AND the path. Neither identifies it alone: a name-only record would also silence a
+  different package that later takes the name, and a path-only one would silence whatever moves in.
+  The `unregistered` finding now prints this command beside the registration command, so both
+  answers are available where the question is asked.
+
+  What a decline does not do: it never touches a finding about a configured entry (`missing`,
+  `relocated`, `ambiguous`, `unverifiable`), never suppresses `discovery_incomplete`, and never
+  hides the other claimants of an ambiguous name. The package is reported again if it moves.
+  `--undecline` withdraws the decision; registering the package clears it in the same write.
+  `refs doctor` says how many decisions a run left unreported, so a quiet check is not a silent
+  one.
+
 ## [0.13.1] - 2026-09-12
 
 ### Upgrading