fix(init): align template package manager with user selection

[benjamincanac]

Summary

Closes #1187.

Some starter templates (e.g. the Nuxt UI starter) ship with a hardcoded packageManager field in package.json (like pnpm@x), plus a pnpm-lock.yaml and pnpm-workspace.yaml. The package manager prompt in nuxi init is seeded from npm_config_user_agent, not the template, so when you pick a different package manager none of that gets cleaned up. you end up with a project still pinned to pnpm even though you chose npm/yarn/bun, which can break installs and confuse later tooling.

This adds an alignPackageManager step that runs right after the package manager is resolved (before install):

• detects the template's package manager via nypm's detectPackageManager (scoped to the template dir with includeParentDirs: false and ignoreArgv: true)
• if it matches the selected one, it's a no-op (the lockfile is kept to speed up install)
• on mismatch, removes the detected PM's lockfile + marker files (e.g. pnpm-workspace.yaml) so install generates a fresh, correct lockfile and nypm won't mis-detect the PM later
• drops the stale packageManager field from package.json

Test plan

• added packages/nuxi/test/unit/commands/init.spec.ts covering mismatch, match, lockfile-without-field, and no-pin cases
• 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: e44e97e

[atinux]

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

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 3b417b41-d1a2-40d1-a496-2536705cb42b

📥 Commits

Reviewing files that changed from the base of the PR and between 5b51db0 and e44e97e.

📒 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 (2)

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

---

📝 Walkthrough

Walkthrough

The PR adds package manager alignment to the init command. When a user initializes a new project and selects a package manager, the alignPackageManager function now reconciles the downloaded template's configuration by detecting its pinned package manager through lockfiles and marker files. If the template's package manager differs from the user's selection, the function removes the incompatible lockfile/marker files and clears any hardcoded packageManager field in package.json, warning on errors rather than failing. This ensures templates with pre-configured package managers (such as pnpm-pinned templates) respect the user's explicit choice.

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 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 (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately and concisely describes the main change: aligning template package managers with user selection in the init command.
Description check	✅ Passed	The description comprehensively explains the problem, solution, and testing approach, directly addressing issue #1187 about templates forcing a hardcoded package manager.
Linked Issues check	✅ Passed	The PR fully addresses issue #1187 by detecting template package manager via nypm, removing conflicting lockfiles/marker files on mismatch, and clearing stale packageManager fields from package.json.
Out of Scope Changes check	✅ Passed	All changes are scoped to the init command enhancement and corresponding unit tests; no unrelated modifications detected.

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

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 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-hq]

Merging this PR will not alter performance

✅ 2 untouched benchmarks

---

_{Comparing fix/init-package-manager-mismatch (e44e97e) with main (9dc5bcc)}

[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 ?