fix(init): use template's package manager instead of prompting

[benjamincanac]

Summary

Closes #1187.

Some starter templates (e.g. the Nuxt UI starter) ship pinned to a package manager — a packageManager field in package.json (like pnpm@x), a lockfile (pnpm-lock.yaml) and/or workspace/config markers (pnpm-workspace.yaml, .yarnrc.yml). The nuxi init package manager prompt is seeded from npm_config_user_agent, not the template, so picking a different one leaves the project in a broken state: a stale lockfile, a mismatched packageManager field, and workspace config that no longer applies.

Rather than cloning the template and stripping those files after the fact (which can silently break a template that relies on its workspace config), this respects the template's choice:

• detects the template's package manager via nypm's detectPackageManager, scoped to the template dir (includeParentDirs: false, ignoreArgv: true)
• when the template pins one, uses it and skips the package manager prompt — the template is left untouched
• an explicit --packageManager still takes precedence, with a warning when it conflicts with the template's pin (its lockfile/config may no longer match)
• when the template pins nothing, behaves as before (prompt, or use --packageManager)

This makes shipping a template that works across package managers a choice for the template author (ship it without a lockfile), as discussed in the PR thread.

Test plan

• reworked packages/nuxi/test/unit/commands/init.spec.ts to cover detection from a lockfile, from the packageManager field, and the no-pin case
• pnpm test

[pkg-pr-new]

• nuxt-cli-playground

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

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

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

commit: aa340fe

[atinux]

Approving as I was involved in pair-programming on this one 😊

[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

The PR detects and respects a downloaded template's pinned package manager during project initialization. A new exported detectTemplatePackageManager helper scopes nypm's detection to the template directory, returning the pinned package manager name or undefined. The init command now calls this helper before resolving the user's package manager choice: if the user explicitly provides --packageManager, it is used with a warning if it differs from the template; if no explicit choice is provided and the template pins a package manager, that choice is auto-selected and logged; otherwise the user is prompted as before. Unit tests verify detection of pnpm via lockfile, yarn via package.json field, and undefined when no package manager is pinned.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

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

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately describes the main change: detecting and using the template's package manager instead of prompting the user.
Linked Issues check	✅ Passed	The PR detects the template's package manager via nypm and auto-selects it when pinned, directly addressing issue #1187's core requirement to prevent template package manager configurations from conflicting with the init process.
Out of Scope Changes check	✅ Passed	All changes are scoped to the init command logic and its unit tests; no unrelated files or functionality have been modified.
Description check	✅ Passed	The PR description is directly related to the changeset, explaining the motivation, implementation, and testing for auto-detecting and respecting template package managers in the init command.

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

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/init-package-manager-mismatch

---

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.}

[codspeed]

Merging this PR will not alter performance

✅ 2 untouched benchmarks

---

_{Comparing fix/init-package-manager-mismatch (aa340fe) with main (1c7c55c)}

[danielroe]

is there a reason you don't want to remove the lockfile from the template?

if it is because it contains workspace config

[benjamincanac]

@danielroe not sure to understand, it does remove the lockfile 🤔 https://github.com/nuxt/cli/pull/1330/changes#diff-02bf0f3c4f7503f4ebacc612fc62c0c6fc3d2e6fb806b5a52afdc72cd939a062R624

[danielroe]

I mean, in the repository which is the template, rather than in nuxt/cli.

[benjamincanac]

Well yes all Nuxt UI templates are deployed on Vercel: https://github.com/nuxt-ui-templates/dashboard. I use renovate to keep the deps up-to-date on a weekly basis to make sure they continue working. It wouldn't be possible without a lockfile.

[danielroe]

it feels like the right fix is to ship a template without a lockfile in the first place, rather than remove it after the fact when nuxt/cli clones it.

I understand you deploy it, and that's great, but how about deploying it without a lockfile? (that way you're always on the latest versions?) or you could have a separate branch or folder which didn't contain the lockfile.

but it's about more than the lockfile. for example, if your pnpm-workspace.yaml contains workspaces configuration, the template would be silently broken after install when this is gone. properly speaking we would need to adapt this configuration to npm workspaces or bun workspaces.

the same might be true for other things and makes me wonder if we're approaching this the wrong way round by 'fixing' it in nuxt/cli. even if we make it work for that particular nuxt/ui template, I'm not sure it would be desired behaviour in general

[benjamincanac]

I don't think it's a good idea to ship a template without a lockfile, first of all it's not practical in development and since any release can break it is not a good experience for the user. It is fine for a starter with a nuxt dependency but not for real world applications like https://chat-template.nuxt.dev/ for example.

This PR only removes the lockfile when the user chooses a different package manager than the one defined in the template.

Should I close this then?

[atinux]

Actually, most of the templates listed on https://nuxt.com/templates or https://hub.nuxt.com/templates also have lock files as this is the most convenient for any developers building a template.

The case of a very specific workspace is very rare IMO, but we could display a (recommended) if we detect the lock file in the template but let the user chose a different package manager, would that work @danielroe ?

[danielroe]

I think the right solution is to ship templates without lockfiles, rather than normalising it after the fact at clone time ...

if you want to deploy or test them with lockfiles, I recommend having templates located in subfolders of a repo, with the lockfile outside the template folders.

alternatively, we could simply avoid asking the user what package manager they want if one is already configured in the template they are cloning.

[atinux]

I think the right solution is to ship templates without lockfiles, rather than normalising it after the fact at clone time ...

There may be a gap in understanding around our ecosystem, how demos are built, and how quickly we want the community to be able to use the template/demo.

Some of our demos/templates have lockfiles: nuxt/hackernews, nuxt/movies

If the issue is about deleting the files, in that case I think the potential solutions are:

1. avoid asking the user the package manager, let hir deal with it after the installation
2. have the possibility to clone repos and filter out the lock files (idea from @pi0)

[danielroe]

I think the right approach for now is to avoid prompting for package manager choice if lock files are present in the template.

then it is a choice on the provider of the template whether they want to provide a template that works in different package managers - or not.

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

packages/nuxi/src/commands/init.ts (1)

150-157: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Non-interactive validation blocks the new template auto-selection path

Line 152 requires --packageManager before template detection runs, so the new fallback on Line 384-Line 387 is unreachable in no-TTY flows. This breaks the intended behavior for CI/agents when the template already pins a package manager.

Suggested fix

-const nonInteractiveRequiredArgs = ['dir', 'template', 'packageManager', 'gitInit'] as const
+const nonInteractiveRequiredArgs = ['dir', 'template', 'gitInit'] as const

Then, after templatePackageManager is resolved:

+    if (isNonInteractive && !packageManagerOptions.includes(packageManagerArg) && !templatePackageManager) {
+      await showUsage(ctx.cmd)
+      logger.error(`Non-interactive terminal detected. Missing required arguments: ${colors.cyan('--packageManager')}`)
+      process.exit(2)
+    }

Also applies to: 367-387

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/nuxi/src/commands/init.ts` around lines 150 - 157, The
non-interactive validation in the isNonInteractive block checks for
packageManager in nonInteractiveRequiredArgs before the template detection logic
runs, making the packageManager auto-selection fallback at lines 384-387
unreachable in no-TTY flows. Move the packageManager validation check to occur
after templatePackageManager is resolved so that when a template pins a package
manager, that resolved value can be used as a fallback instead of failing the
validation upfront.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Outside diff comments:
In `@packages/nuxi/src/commands/init.ts`:
- Around line 150-157: The non-interactive validation in the isNonInteractive
block checks for packageManager in nonInteractiveRequiredArgs before the
template detection logic runs, making the packageManager auto-selection fallback
at lines 384-387 unreachable in no-TTY flows. Move the packageManager validation
check to occur after templatePackageManager is resolved so that when a template
pins a package manager, that resolved value can be used as a fallback instead of
failing the validation upfront.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: a2529ed6-dca8-4926-ace6-5a19aa0b8970

📥 Commits

Reviewing files that changed from the base of the PR and between 2d240b0 and dab8fd5.

📒 Files selected for processing (2)

• packages/nuxi/src/commands/init.ts
• packages/nuxi/test/unit/commands/init.spec.ts

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

• packages/nuxi/test/unit/commands/init.spec.ts

[benjamincanac]

@danielroe I've applied your suggestions!

[danielroe]

❤️