fix(dev): resolve package versions via their parents

[BellYun]

🔗 Linked issue

Refs nuxt/nuxt#34809 — this covers the CLI side. The devtools side is in nuxt/devtools#986.

📚 Description

Resolves vite via nuxt -> @nuxt/vite-builder -> vite instead of resolving it directly from cwd.
Under pnpm 11's enableGlobalVirtualStore, vite is not reachable from CWD or nuxt itself. However, since @nuxt/vite-builder declares vite as a direct dependency, the lookup now works correctly through that path.

• Verified against a pnpm 11 globalVirtualStore repro.
• Added a regression test.

[pkg-pr-new]

• nuxt-cli-playground

  npm i https://pkg.pr.new/create-nuxt@1283
  

  npm i https://pkg.pr.new/nuxi@1283
  

  npm i https://pkg.pr.new/@nuxt/cli@1283
  

commit: a8ef670

[codspeed-hq]

Merging this PR will not alter performance

✅ 2 untouched benchmarks

---

_{Comparing BellYun:fix/banner-null-guard (a8ef670) with main (ab01307)}

[coderabbitai]

📝 Walkthrough

Walkthrough

The PR updates package version resolution and builder detection. banner.ts: getBuilder now calls getPkgJSON(cwd, 'vite', { via: '@nuxt/vite-builder' }), uses null-safe checks (pkgJSON?.name?.includes('rolldown')) and falls back to 'unknown' for missing versions. versions.ts: getPkgVersion and getPkgJSON signatures gain an optional options?: { via?: string }; getPkgJSON builds a roots/searchFrom list and, when options.via resolves, adds that module path to the search order before looking for ${pkg}/package.json. A new Vitest unit test exercises getBuilder behavior with mocked getPkgJSON/getPkgVersion.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description check	✅ Passed	The description provides relevant context about the issue (pnpm 11 globalVirtualStore isolation), the solution (resolving vite via @nuxt/vite-builder), verification details, and mentions a regression test, all of which align with the changeset.
Title check	✅ Passed	The title 'fix(dev): resolve package versions via their parents' accurately describes the main change—implementing a resolution strategy that finds packages through their parent dependencies, specifically vite via @nuxt/vite-builder.

_{✏️ 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]

🧹 Nitpick comments (2)

packages/nuxi/test/unit/utils/banner.spec.ts (1)

13-16: Add coverage for the @nuxt/vite-builder alias path as well.

Both 'vite' and '@nuxt/vite-builder' hit the same switch branch; asserting both reduces regression risk.

🧪 Suggested test addition

 describe('getBuilder', () => {
   // regression for banner crash under pnpm globalVirtualStore
   // where vite is unreachable from cwd — getPkgJSON returns null
   it('does not throw when vite package.json cannot be resolved', () => {
     expect(() => getBuilder('/any', 'vite')).not.toThrow()
     expect(getBuilder('/any', 'vite')).toMatchObject({ name: 'Vite', version: '' })
+    expect(() => getBuilder('/any', '@nuxt/vite-builder')).not.toThrow()
+    expect(getBuilder('/any', '@nuxt/vite-builder')).toMatchObject({ name: 'Vite', version: '' })
   })
 })

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/nuxi/test/unit/utils/banner.spec.ts` around lines 13 - 16, Add a
second assertion in the existing test case to cover the alias path
'@nuxt/vite-builder' as well: call getBuilder('/any', '@nuxt/vite-builder') and
assert it does not throw and matches { name: 'Vite', version: '' }, mirroring
the existing assertions for getBuilder('/any', 'vite') in the same it block to
ensure both branches hitting the Vite case are covered.

packages/nuxi/src/utils/banner.ts (1)

21-21: Consider avoiding empty builder versions in returned metadata.

Line 21 can return version: '', which flows into packages/nuxi/src/commands/info.ts (Line 112) and renders as vite@. Consider either a non-empty sentinel or formatter-side omission of @ when version is empty.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/nuxi/src/utils/banner.ts` at line 21, The builder metadata currently
returns version: '' when pkgJSON.version is missing, causing consumers to render
bare "vite@" strings; update the return object in banner.ts (the object with
name and version) to use a non-empty sentinel or omit the property when absent —
e.g., set version: pkgJSON?.version ?? undefined or only include version when
truthy so downstream code (the info rendering) can skip the "@".

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@packages/nuxi/src/utils/banner.ts`:
- Line 21: The builder metadata currently returns version: '' when
pkgJSON.version is missing, causing consumers to render bare "vite@" strings;
update the return object in banner.ts (the object with name and version) to use
a non-empty sentinel or omit the property when absent — e.g., set version:
pkgJSON?.version ?? undefined or only include version when truthy so downstream
code (the info rendering) can skip the "@".

In `@packages/nuxi/test/unit/utils/banner.spec.ts`:
- Around line 13-16: Add a second assertion in the existing test case to cover
the alias path '@nuxt/vite-builder' as well: call getBuilder('/any',
'@nuxt/vite-builder') and assert it does not throw and matches { name: 'Vite',
version: '' }, mirroring the existing assertions for getBuilder('/any', 'vite')
in the same it block to ensure both branches hitting the Vite case are covered.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 3e6e987f-ba2b-4d40-a0ae-4a760362b829

📥 Commits

Reviewing files that changed from the base of the PR and between e14ce27 and e4d695e.

📒 Files selected for processing (2)

• packages/nuxi/src/utils/banner.ts
• packages/nuxi/test/unit/utils/banner.spec.ts

[codecov-commenter]

Codecov Report

❌ Patch coverage is 96.00000% with 1 line in your changes missing coverage. Please review.
⚠️ Please upload report for BASE (main@ab01307). Learn more about missing BASE report.

Files with missing lines	Patch %	Lines
packages/nuxi/src/utils/versions.ts	94.44%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1283   +/-   ##
=======================================
  Coverage        ?   49.64%           
=======================================
  Files           ?       49           
  Lines           ?     1257           
  Branches        ?      349           
=======================================
  Hits            ?      624           
  Misses          ?      516           
  Partials        ?      117           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[danielroe]

would you be able to go ahead and address the root cause? 🙏

I did some tinkering on the plane just now and I'm pretty sure we need to be able to resolve nuxt -> @nuxt/vite-builder -> vite instead of the current approach of directly trying to resolve vite.

[BellYun]

would you be able to go ahead and address the root cause? 🙏

I did some tinkering on the plane just now and I'm pretty sure we need to be able to resolve nuxt -> @nuxt/vite-builder -> vite instead of the current approach of directly trying to resolve vite.

It was just a stopgap. I felt it was urgent to stop the crash first since it's a pretty bad experience for users. Already looking into the nuxt -> @nuxt/vite-builder -> vite path now.

I'll update this PR

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@packages/nuxi/src/utils/versions.ts`:
- Around line 24-38: The search order currently pushes the resolved viaPath
after existing roots so resolution still prefers cwd/Nuxt; change the logic that
handles options?.via in the block that iterates roots so the resolved viaPath
(from resolveModulePath(options.via, { from, try: true })) is placed before the
generic roots — e.g. insert/unshift the viaPath into searchFrom (or build
searchFrom starting with viaPath) and then break — ensuring the via root is
prioritized when the subsequent loop over searchFrom resolves
`${pkg}/package.json`.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 705b7b64-55c5-427a-bd67-cfe58fe7c4f9

📥 Commits

Reviewing files that changed from the base of the PR and between e4d695e and 788c248.

📒 Files selected for processing (3)

• packages/nuxi/src/utils/banner.ts
• packages/nuxi/src/utils/versions.ts
• packages/nuxi/test/unit/utils/banner.spec.ts

🚧 Files skipped from review as they are similar to previous changes (2)

• packages/nuxi/src/utils/banner.ts
• packages/nuxi/test/unit/utils/banner.spec.ts

[BellYun]

@danielroe I've addressed the root cause by resolving via nuxt -> @nuxt/vite-builder -> vite instead of direct lookup.

Also added a regression test for pnpm 11 globalVirtualStore.

One more thing — it looks like the CodeQL check is stuck in "waiting for results" (possibly due to fork PR restrictions). Would you mind re-running it or taking a look?

Thanks!

[danielroe]

thank you ❤️