I am deploying my portfolio on vercel but i am getting error due to pnpm 10.4
ERR_PNPM_LOCKFILE_CONFIG_MISMATCH Cannot proceed with the frozen installation. The current "patchedDependencies" configuration doesn't match the value found in the lockfile this will occured with pnpm latest version 10.4. when i try with pnpm 9 it passes smoothly.
Hi, Shyam! Welcome to the Vercel Community 
Thank you for reporting! We’re aware of this and are working on supporting pnpm@10.
I’ll keep you updated 
Hello!
It sounds like your project is using pnpm@10 in Vercel CI while you are using pnpm@9 locally? If so, this problem is not actually caused by pnpm@10. This will also happen with pnpm@9 in Vercel CI due to pnpm’s frozen lockfile feature which is enabled in CI environments.
To fix this error, update your lockfile with pnpm i.
If you want to match your local environment and use pnpm@9 instead of pnpm@10 for this project, you can enable Corepack.
Hope this helps, and happy to answer any follow up questions!
I had already enabled corepack like that "packageManager": "pnpm@10.5.2",. I am using pnpm@10.5.2 in locally but deployment time the vercel says using pnpm@9.x to use pnpm@10.x enable corepack but i had already enabled.\
So, help me.
We just shipped pnpm v10 support. Let us know if that helps!
To enable corepack on Vercel, you also need to add the environment variable with name ENABLE_EXPERIMENTAL_COREPACK and value 1 to your project. If you already have a package.json#packageManager defined to some version of pnpm 9, that should do the trick!
See more info about enabling corepack here.
The packageManager field does not allow for version ranges. I don’t want to suddenly force developers to use corepack with a fixed version of pnpm now, just to get Vercel to follow suit.
What about following the engines field or adding an environment variable?
Hi Dan,
Corepack is generally considered better than the engines field for package manager version management because it provides a more robust and consistent experience, especially for projects where different package managers might be preferred. It allows for a clear definition of the specific package manager and its version used within a project, making it easier to ensure reproducible builds and consistent development environments across different machines or environments.
Since Node.js is also slowly working to make Corepack Stable. We will likely monitor how Node.js progress development of Corepack in future and go with the same direction.
fyi, Corepack will be unbundled from Node.js and no longer directly distributed in future Node versions which is such an inconvenience.
Sources:
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.
