-
-
Notifications
You must be signed in to change notification settings - Fork 6
Description
Bug Report
TanStack Intent version: v0.0.23
Runtime: Node.js v24.x
Package manager: npm v10.x
Description
Running intent stale --json in a monorepo with private scoped packages (published to GitHub Packages) returns currentVersion: null for every package, preventing version drift detection from working.
Root cause: fetchNpmVersion() in staleness.ts hardcodes https://registry.npmjs.org/ — any package not on the public npm registry returns a 404, silently breaking drift detection.
Steps to reproduce
- Create a package with
tanstack-intentkeyword andskills/directory - Add
library_versionto skill frontmatter - Publish to a private registry (GitHub Packages, Artifactory, etc.)
- Run
npx @tanstack/intent@latest stale --json - Observe
currentVersion: nullandversionDrift: null
Expected: currentVersion should reflect the package's actual version. Since checkStaleness already receives packageDir, reading the local package.json version would work for both maintainer workspaces and consumer node_modules.
Minimal Reproducible Example
Any package scoped to a private registry (e.g. @myorg/my-lib on GitHub Packages). The fetchNpmVersion function always queries registry.npmjs.org, which returns 404 for packages not published there.
Additional context
I noticed #102 fixes monorepo path resolution for stale — this is the complementary fix for version resolution. I am also opening a PR with a suggested fix that reads the local package.json version first, falling back to the npm registry.
Two related documentation gaps worth noting (separate from this fix):
library_versionis the expected frontmatter field for drift detection but is not documented in the maintainer quick-start guidesync-state.jsonis read by the staleness checker but no CLI command generates it, so source-level staleness tracking does not function yet