Fix package manager detection to respect packageManager field in monorepos

[Copilot]

This PR fixes an issue where ultracite init would use the wrong package manager in monorepos when there was a conflict between the explicit packageManager field in package.json and existing lockfiles.

Problem

When running ultracite init in a monorepo with:

• A packageManager field specifying bun (e.g., "packageManager": "bun@1.0.0")
• An existing pnpm-lock.yaml file from previous usage
• A workspaces field indicating monorepo structure

Ultracite would incorrectly use pnpm add -w instead of respecting the explicit bun add configuration, leading to errors like:

 ERROR  This project is configured to use bun
For help, run: pnpm help add
Failed to run Ultracite: Command failed: pnpm add -D --save-exact ultracite @biomejs/biome@1.9.4

Solution

Modified the package manager detection logic in scripts/package-manager.ts to:

1. Check packageManager field first - Parse the field from package.json (e.g., "bun@1.0.0" → "bun")
2. Fall back to lockfile detection - Only check for lockfiles if no explicit packageManager is specified
3. Maintain monorepo support - Apply appropriate workspace flags based on the detected package manager

Changes

• Updated packageManager.get() to prioritize explicit configuration over lockfile detection
• Added comprehensive test coverage with 11 new test cases covering various scenarios
• Maintained backward compatibility and all existing functionality

Testing

Before:

●  Detected lockfile, using pnpm add -w  # ❌ Wrong - from lockfile

After:

●  Detected lockfile, using bun add      # ✅ Correct - from packageManager field

• All 212 existing tests pass
• Manual validation confirms proper detection in monorepo scenarios
• Fallback behavior works when packageManager field is absent

Fixes #188.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
ultracite	❌ Failed (Inspect)			Jul 13, 2025 9:35pm

[haydenbleasel]

@copilot please rebase

[Copilot]

@copilot please rebase

I understand you'd like me to rebase this branch, but due to security limitations, I cannot perform git rebase operations that require force pushing.

The branch is currently based on v5.0.34 while main is at v5.0.44. Would you prefer me to:

1. Manually recreate the changes on the latest main branch, or
2. Is there a different approach you'd like me to take?

I can apply the same package manager detection fixes to the current main branch if that would work better.