<aside> 🚧

Note: This document collects my development notes and has been organized and translated into English with the help of AI. Some phrasing may be awkward, and there may be mistakes. Please feel free to point out any errors.

</aside>

1. Problem Statement

When creating a new project via npx create-electron-app (or npx create-electron-app@latest), the package manager detection always defaults to npm.

This happens because:

• The user-agent at runtime is npm/npx.
• At the very beginning, no lockfile exists.

As a result, initialization (template copy, package.json merge, config setup) always proceeds with npm assumptions. Later switching to pnpm install (or Yarn Berry) leaves the project missing important package-manager–specific defaults (e.g., .npmrc, pnpm.onlyBuiltDependencies, hoist settings).

With pnpm v10, lifecycle script execution changes mean that postinstall no longer compensates for this mismatch. The end state becomes a “mixed npm + pnpm project,” leading to errors and user confusion.

2. Root Causes

• Lack of input/hint at init time: no lockfile, npm user-agent → current resolvePackageManager() logic (user-agent → lockfile → NODE_INSTALLER → fallback) can’t detect pnpm/yarn.
• Dual detection: even if a PM is chosen once, templates may call resolvePackageManager() again and return a different result.
• Postinstall reliance: some templates assume PM-specific setup will run during postinstall, but this no longer holds reliably.

Conclusion: without a single explicit PM decision at init, template logic can’t execute safely or consistently.

3. Considered Alternatives

• A. CLI flag (-package-manager) → explicit, fast.
• B. Environment variable (e.g. FORGE_PACKAGE_MANAGER) → simple, but global dependency.
• C. package.json.packageManager field in template → standards-based, template-only.
• D. Bundled lockfile → possible, but confusing.