amplify always chooses the wrong package manager

[thegrandpoobah]

How did you install the Amplify CLI?

npm

If applicable, what version of Node.js are you using?

16.20.2

Amplify CLI Version

12.12.6

What operating system are you using?

Linux (and Windows WSL)

Did you make any manual changes to the cloud resources managed by Amplify? Please describe the changes made.

No

Describe the bug

amplify push (or pull) always chooses yarn for me (and pnpm for a developer on my team) even though the package manager we've been using is npm and there is a package-lock.json file in the repo.

We've been away from this project for a couple months and we haven't made ANY changes to the repo/project/amplify and this behaviour just started when we upgraded our amplify. Not sure which version we were running prior.

Expected behavior

Use npm as was being done before.

Reproduction steps

just type amplify pull or amplify push on our project that has a package-lock.json in the root
Please note: there is not a yarn.lock file anywhere to be seen in this amplify project folder structure. I have made tripley sure of this.

Project Identifier

f692ebb27a73e75af29c87f79f8db1e0

Log output

Fetching updates to backend environment: dev from the cloud.⠋ Building resource api/AdminQuerie⠼ Building resource api/lambdaserverlessadmi⚠️ WARNING: owners may reassign ownership for the following model(s) and role(s): Profile: [owners], Customer: [owners]. If this is not intentional, you may want to apply field-level authorization rules to these fields. To read more: https://docs.amplify.aws/cli/graphql/authorization-rules/#per-user--owner-based-data-access.
⠦ Building resource api/lambdaserverlessadmi✅ GraphQL schema compiled successfully.

Edit your schema at /amplify/backend/api/lambdaserverlessadmi/schema.graphql or place .graphql files in a directory at /amplify/backend/api/lambdaserverlessadmi/schema
✖ Fetching updates to backend environment: dev from the cloud.
✖ There was an error initializing your environment.
🛑 Packaging overrides failed.
Command failed with exit code 1: yarn install
warning package.json: No license field
warning package-lock.json found. Your project contains lock files generated by tools other than Yarn. It is advised not to mix package managers in order to avoid resolution inconsistencies caused by unsynchronized lock files. To clear this warning, remove package-lock.json.
... and lots more yarn failures

Additional information

I fixed this by deleting yarn from my computer. My colleague fixed it by renaming her pnpm binary.

Before submitting, please confirm:

• I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.
• I have removed any sensitive information from my code snippets and submission.

[ykethan]

Hey @thegrandpooba, thank you for reaching out. It appears the behavior is occurring due to following

amplify-cli/packages/amplify-cli-core/src/utils/packageManager.ts

Lines 109 to 118 in a644a1f

	/**
	* Detect the package manager in the passed in directory or process.cwd, with a preference to yarn over npm
	* 1. Check if a package.json file present in the directory as it is mandatory, if not return null
	* 2. Check if yarn.lock is present and yarn is present and .yarnrc.yml is present on the system for yarn2
	* 3. Check if yarn.lock is present and yarn is present on the system
	* 4. Check if package-lock.json is present
	* 5. Check if yarn present on the system
	* 6. Fallback to npm
	@returns {PackageManager | null} instance for the package manager that was detected or null if not found.
	*/

To mitigate the issue you could try removing the yarn.lock and node_modules from the amplify/backend directory then install using your preferred package manager in the amplify/backend which should switch the package manager.

[thegrandpoobah]

Thanks for your note, but I do not have yarn.lock file anywhere in my repository (i have now quadruple checked). There is only package-lock.json. It also doesn't explain why it picks pnpm for my colleauge (no pnpm-lock.yaml in this repository either)

[ykethan]

apologies on the delay in a response.
diving into the code

amplify-cli/packages/amplify-cli-core/src/utils/packageManager.ts

Lines 130 to 156 in a644a1f

	tempFilePath = path.join(effectiveRootPath, packageManagers.pnpm.lockFile);
	if (fs.existsSync(tempFilePath) && checkExecutable(packageManagers.pnpm.executable)) {
	return packageManagers.pnpm;
	}
	// checks for yarn
	tempFilePath = path.join(effectiveRootPath, packageManagers.yarn.lockFile);
	if (fs.existsSync(tempFilePath) && checkExecutable(packageManagers.yarn.executable)) {
	return getYarnPackageManager(rootPath);
	}
	// checks for npm
	tempFilePath = path.join(effectiveRootPath, packageManagers.npm.lockFile);
	if (fs.existsSync(tempFilePath)) {
	return packageManagers.npm;
	}
	// no lock files found
	if (checkExecutable(packageManagers.yarn.executable)) {
	return getYarnPackageManager(rootPath);
	}
	if (checkExecutable(packageManagers.pnpm.executable)) {
	return packageManagers.pnpm;
	}
	return packageManagers.npm;

it appears the code checks for any lock file first present in the directory:
The order of check: pnpm -> yarn -> npm
if it does not find any lock files it proceeds to check for a locally installed package manager executable:
The order of the check: yarn -> pnpm -> npm

Marking this as bug for further investigation and improvements.