[EAS Build] EAS Build should adhere to the package manager version set in package.json

[pmk1c]

I was confused at first, when I noticed that EAS ignores the packageManager field in package.json. I think this should be the first place to look for, when EAS decides, which package manager and which version to use.

[szdziedzic]

Hi @pmk1c,

It makes sense. I will try to add support for it and make it the first place to look for package manager + its version 👍

[expo-bot]

Thank you for filing this issue!
This comment acknowledges we believe this may be a bug and there’s enough information to investigate it.
However, we can’t promise any sort of timeline for resolution. We prioritize issues based on severity, breadth of impact, and alignment with our roadmap. If you’d like to help move it more quickly, you can continue to investigate it more deeply and/or you can open a pull request that fixes the cause.

[expo-bot]

Thank you for filing this issue!
This comment acknowledges we believe this may be a bug and there’s enough information to investigate it.
However, we can’t promise any sort of timeline for resolution. We prioritize issues based on severity, breadth of impact, and alignment with our roadmap. If you’d like to help move it more quickly, you can continue to investigate it more deeply and/or you can open a pull request that fixes the cause.

[FedeRBeije]

Hello, i'm using turborepo monorepo and trying to build some apps.

If in my root there is a packageManager prop like this:

that is automatically added by turborepo, i'd get this error in eas log:

We detected that 'APP_NAME' is a yarn workspace
Running "yarn install" in /Users/expo/workingdir/build directory
error This project's package.json defines "packageManager": "yarn@[email protected]". However the current global version of Yarn is 1.22.21.
Presence of the "packageManager" field indicates that the project is meant to be used with Corepack, a tool included by default with all official Node.js distributions starting from 16.9 and 14.19.
Corepack must currently be enabled by running corepack enable in your terminal. For more information, check out https://yarnpkg.com/corepack.
yarn install exited with non-zero code: 1

Do you have any suggestion of why is happening?

Also i'm using npm as package manager.

Thank you

[FedeRBeije]

@szdziedzic sorry to ping you but it would be helpful to know something about it.

Thanks

[SanderPeeters]

I think I have the same issue:
In my monorepo's root package.json, I've set "packageManager": "[email protected]"
When creating a custom build config and building it on EAS build, I receive an error in the Install node_modules step.
It's weird that it says yarn@[email protected] while there's obviously just [email protected] in my package.json.

Any ideas?

[szdziedzic]

Hi @SanderPeeters,

I assume you want to use NPM as your project manager, right? Do you have a lock file generated by yarn in your repo by any chance?

[SanderPeeters]

Hi @SanderPeeters,

I assume you want to use NPM as your project manager, right? Do you have a lock file generated by yarn in your repo by any chance?

Hi, thx for answering me! It's correct that I want NPM to use as a package manager. I have a package-lock.json file in my root folder, but no yarn.lock. When I'm creating a 'regular' build (not using he custom build scheme), it correctly detects that there's a package-lock.json file. But the custom build scheme doesn't recognize this for some reason.

[szdziedzic]

Hi, thx for answering me! It's correct that I want NPM to use as a package manager. I have a package-lock.json file in my root folder, but no yarn.lock. When I'm creating a 'regular' build (not using he custom build scheme), it correctly detects that there's a package-lock.json file. But the custom build scheme doesn't recognize this for some reason.

I will check if I can replicate it, thanks!

[szdziedzic]

@SanderPeeters @FedeRBeije

I deployed a PR to fix the package manager resolution logic for custom builds. Can you check if it fixed your issue?

[szdziedzic]

Please note: It still doesn't mean we added support for the packageManager field in package.json all across EAS Build. This PR should just fix package manager resolution logic based on the presence of lock files.

[FedeRBeije]

Hi @szdziedzic. With eas-cli/10.2.1 darwin-x64 node-v18.19.0 it worked fine.

To be honest the first build failed because during the post-install(need to do this right know has i mention #2463)
it couldn't find a packageManager prop inside package.json.

Thank you so much!

[github-actions]

This issue is stale because it has been open for 30 days with no activity. If there is no activity in the next 7 days, the issue will be closed.

[github-actions]

This issue was closed because it has been inactive for 7 days since being marked as stale. Please open a new issue if you believe you are encountering a related problem.