bug: Vercel deployment fails

[technophile-04]

Is there an existing issue for this?

• I have looked through the existing issues

Current Behavior

Running : yarn vercel

Steps To Reproduce

Alternatively to reproduce locally :
Update viem and wagmi to latest version :
1.yarn workspace @se-2/nextjs up wagmi viem

Run check-types :
2.yarn next:check-types

However through above steps you get different type errors then vercel :

Anything else?

I think the reason its failing on vercel deployement and not locally is because since we have ^ for viem and wagmi in package.json because of which on Vercel while yarn install it gets latest patch version of both viem and wagmi and it seems that in latest viem and wagmi its broken.

I think this problem is again related to -> wevm/wagmi#2421 (comment)

[carletex]

Thanks for reporting this Shiv.

What I don't understand is why Vercel installs a different version of the packages. Even if we have ^ in package.json, it should take the exact version from yarn.lock (that's the goal of this file!)

[technophile-04]

What I don't understand is why Vercel installs a different version of the packages. Even if we have ^ in package.json, it should take the exact version from yarn.lock (that's the goal of this file!)

Yeah this makes sense !!

I tried going through the deployment logs and found this :

Also if you look at the souce uploaded it dosen't have yarn.lock (I think because we are just uploading nextjs workspace and yarn.lock is present at root ?)

[carletex]

Oh damn, you are right @technophile-04!! Thanks for looking into it.

Maybe we could explore if there is a way to make a dedicated yarn.lock for each package?? (this will also be great for the CLI)

I think we can merge PRs #420 #421 for now

[carletex]

Another option is to make the root yarn.lock avaliable on the Vercel build (I think we look for something similar when playing with moving the scaffold.config.ts to the root of the repo)

[technophile-04]

Maybe we could explore if there is a way to make a dedicated yarn.lock for each package?? (this will also be great for the CLI)

Yes yes will research on this nicely

Another option is to make the root yarn.lock available on the Vercel build (I think we look for something similar when playing with moving the scaffold.config.ts to the root of the repo)

Yup but with this option we had to mention root directory manually while deployemnt :( checkout point 1. of -> #231 (comment)

I have also created some discussion on vercel regarding this :
vercel/vercel#10211
https://github.com/orgs/vercel/discussions/2145

Nevertheless, I like the first option more having a dedicated yarn.lock if that's feasible but let's see 🙌

[technophile-04]

Maybe we could explore if there is a way to make a dedicated yarn.lock for each package?? (this will also be great for the CLI)

I found this -> yarnpkg/berry#1223 think there is no direct solution to doing this in yarn :( .... There are some hacky solutions mentioned in the issue using some people's plugin but I went through and didn't find any stable, well maintained and famous

cc @rin-st @sverps also if they have some better approach or if I am missing and there might an easy solution already (because I feel this should have been present in yarn already).

Also just mentioning pnpm here 😅 (It's workspaces has this option to create separate lock files) ....I tried it out and its really good also we might also benefit from it using it in our CLI due to its some what faster installations

[carletex]

Also just mentioning pnpm here sweat_smile (It's workspaces has this option to create separate lock files) ....I tried it out and its really good also we might also benefit from it using it in our CLI due to its some what faster installations

We kept using yarn for historical reasons and it was easy to set up. But I won't be opposed to switching to pnpm if we have a good reason for it (like the per-package lock files) It supports monorepos too and it seems to be super fast.

But yarn chain etc is a classic in SE, so it looks like a big deal to me haha. I just texted Austin to get his take.

But also let's make sure that there isn't an easier solution that doesn't imply switching.

[rin-st]

I believe pnpm is a good solution.

[carletex]

@technophile-04 could you draft a PR (against main) for the pnpm "tests" that you made when you have the chance? So we can also see how pnpm looks on SE-2.

I really like the individual lock files, and it seems that's a modern and performant solution.

[technophile-04]

@technophile-04 could you draft a PR (against main) for the pnpm "tests" that you made when you have the chance? So we can also see how pnpm looks on SE-2.

For sure !!!! lol I deleted all the changes but the migration is pretty much straightforward forward and easy so will draft a PR soon 🙌