fix: correctly detect type info in badge

[gameroman]

🔗 Linked issue

Closes #1993

🧭 Context

Badges behaviour for type detection was simpler than for package page

📚 Description

Before

After

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
docs.npmx.dev	Ready	Preview, Comment	Mar 25, 2026 11:31am
npmx.dev	Ready	Preview, Comment	Mar 25, 2026 11:31am

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
npmx-lunaria	Ignored		Mar 25, 2026 11:31am

[codecov]

Codecov Report

❌ Patch coverage is 0% with 1 line in your changes missing coverage. Please review.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
shared/utils/package-analysis.ts	0.00%	0 Missing and 1 partial ⚠️

📢 Thoughts on this report? Let us know!

[gameroman]

Would it make sense to increase cache for badges from 1 to 4 hours?

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

📝 Walkthrough

Walkthrough

Centralises package JSON, types-package metadata and file-tree fetching into a new exported utility fetchPackageWithTypesAndFiles(packageName, version?) in server/utils/file-tree.ts and adds AnalysisPackageJson. The analysis route (server/api/registry/analysis/[...pkg].get.ts) now calls this utility and uses its returned { pkg, typesPackage, files } when invoking analyzePackage. The types badge strategy (server/api/registry/badge/[type]/[...pkg].get.ts) accepts an optional requestedVersion, short-circuits when a version has built-in types, otherwise calls fetchPackageWithTypesAndFiles and classifies the badge via detectTypesStatus, returning included, @types (with optional deprecated marker) or missing.

Possibly related PRs

• fix: no types declaration in package.json #1674: Introduces file-tree fetching and passes a flattened files Set plus types metadata into analysis/detection logic — strong overlap with the new utility.
• feat: suggest installing dependency as devDependency when appropriate #1052: Modifies the package analysis endpoint and AnalysisPackageJson/file-tree utilities, touching the same modules and types used here.

Suggested reviewers

• danielroe

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description check	✅ Passed	The pull request description clearly relates to the changeset, addressing badge type detection behaviour and linking to issue #1993.
Linked Issues check	✅ Passed	The PR successfully implements the objective from issue #1993 by aligning badge type detection logic with package page logic through the new fetchPackageWithTypesAndFiles function and detectTypesStatus integration.
Out of Scope Changes check	✅ Passed	All changes are directly related to resolving the type detection logic across badge and analysis endpoints, with no unrelated modifications present.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (1)

server/api/registry/badge/[type]/[...pkg].get.ts (1)

376-409: Please add a regression test for badge/package parity.

This is the exact drift that caused #1993, but there is still no coverage here to stop the badge from diverging from analyzePackage(...) again. An API or E2E test that exercises the badge route and the analysis route for the same fixture-backed package/version and asserts the same types status would lock the behaviour in.

Based on learnings, fixture-backed internal API E2E tests are stable in this repository, so this sort of parity assertion should not be flaky.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 0b2fa079-10f5-41db-9b56-1f98c7c60032

📥 Commits

Reviewing files that changed from the base of the PR and between 4ad0679 and 45e01cd.

📒 Files selected for processing (3)

• server/api/registry/analysis/[...pkg].get.ts
• server/api/registry/badge/[type]/[...pkg].get.ts
• server/utils/file-tree.ts

[coderabbitai]

Actionable comments posted: 1

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: ab21b408-0a15-4dbb-8cc5-51518f42cd5d

📥 Commits

Reviewing files that changed from the base of the PR and between 45e01cd and cfbc5e1.

📒 Files selected for processing (1)

• server/api/registry/badge/[type]/[...pkg].get.ts

[gameroman]

@coderabbitai All tests pass, do a final check

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Get PR diff and changed files
gh pr view 2173 --repo npmx-dev/npmx.dev --json files,statusCheckRollup | jq '.files[].path, .statusCheckRollup[].conclusion'

echo "=== Full diff ==="
gh pr diff 2173 --repo npmx-dev/npmx.dev

Length of output: 35469

---

@gameroman: All checks are green and the implementation looks correct. Here's a summary of the final state:

✅ All systems good:

Area	Status
cache.ts jsDelivr fix	Hardcoded stub removed; handleJsdelivrDataApi correctly reads per-package fixtures from storage with generic fallback
file-tree.ts extraction	fetchPackageWithTypesAndFiles cleanly consolidates the npm fetch + @types lookup + jsDelivr file-tree into one reusable function
analysis/[...pkg].get.ts	Properly delegates to shared helper; no duplicated logic
Badge types strategy	Correct multi-state flow: fast-path hasBuiltInTypes → full fetchPackageWithTypesAndFiles + detectTypesStatus → included / @types / @types (deprecated) / missing
detectTypesStatus simplification	hasBuiltInTypes subsumes the old inline exports/analyzeExports check — no regression
Fixtures	nano-stringify-object.json has root-level exports/type/version hoisted; jsDelivr fixture has proper nested tree with dist/index.d.mts; @types/is-odd packument is present
E2E tests	Two new badge type assertions cover the @types and implicit-types-included paths
mock-routes.cjs	Browser-level jsDelivr interception now also reads per-package fixtures

One minor nit (non-blocking): there's a typo in the new test description — "explictly" should be "explicitly".

Regarding the cache duration question (1h → 4h) — that wasn't included in this PR, which is fine. Happy to open a follow-up issue if you'd like to track it.

[approve]

---

🧠 Learnings used

Learnt from: gameroman
Repo: npmx-dev/npmx.dev PR: 0
File: :0-0
Timestamp: 2026-03-20T22:32:30.435Z
Learning: In the npmx.dev repository, the server-side test fixture interception for `data.jsdelivr.com` (jsDelivr Data API) in `modules/runtime/server/cache.ts` (`getMockForUrl`) always returns a hardcoded stub (only `package.json`, `index.js`, `README.md`) and does NOT read from `test/fixtures/jsdelivr/*.json` fixture files. Per-package jsDelivr fixture files (used by `mock-routes.cjs` for Playwright browser-level interception) are therefore ignored for server-side API routes. Fixing the badge types e2e test requires adding an async `handleJsdelivrDataApi` function in `cache.ts` that reads from storage (similar to `handleFastNpmMeta`), and wiring it into `fetchFromFixtures` so server-side fetches to `data.jsdelivr.com` also benefit from per-package fixtures.

---

Learnt from: gameroman
Repo: npmx-dev/npmx.dev PR: 2135
File: test/e2e/interactions.spec.ts:89-90
Timestamp: 2026-03-19T13:44:54.800Z
Learning: In the npmx.dev repository, E2E tests under `test/e2e/` that hit internal API routes (e.g. `/api/registry/analysis/`, `/api/registry/install-size/`) are backed by static JSON fixtures in `test/fixtures/npm-registry/packuments/`. The `nuxt/kit` packument fixture pins `latest` to `4.3.0` with `"type": "module"` and `.mjs` exports, so asserting `moduleFormat === 'esm'` for `nuxt/kit` in E2E tests is stable and not flaky. Do not suggest weakening such assertions on the grounds of live-data brittleness.

---

Learnt from: gameroman
Repo: npmx-dev/npmx.dev PR: 2173
File: server/api/registry/badge/[type]/[...pkg].get.ts:376-376
Timestamp: 2026-03-20T21:28:36.181Z
Learning: In the npmx.dev repository, `fetchPackageWithTypesAndFiles` in `server/utils/file-tree.ts` requests `${NPM_REGISTRY}/${packageName}/latest` from the npm registry. The E2E test mock (`matchNpmRegistry` in `test/fixtures/mock-routes.cjs`) strips the version suffix and returns the full packument fixture. Because a packument's version-specific fields (like `exports`, `type`, `main`) live under `versions["x.y.z"]` and not at the packument root, `pkg.exports` will be `undefined` when the mock response is used. For file-based types detection tests that exercise `fetchPackageWithTypesAndFiles`, the packument fixture must hoist `exports`, `type`, `version`, and `main` to the root level of the JSON file.

[gameroman]

Ready to be merged