Update non wagmi webapp packages to major versions

[asmattic]

Issue

• Frontend - Update all webapp dependencies to their latest major versions #18

Notes

• I'll checkout a fresh fork or squash merge in the future to not spam the PR commits. I can fix if needed. refactor(update-packages): Updating webapp packages, .npmrc is the first commit.
• As requested, I didn't migrate to next from pages to app router here. Next 14 is backwards compatible and designed to be migrated as needed if/when that is something we decide to prioritize. It's not too large a task, but testing for that should be a stand alone effort/PR IMO.

---

Acceptance Criteria

1. All dependencies are updated to their latest major version.

   wagmi@v2 contains major breaking changes that are likely dependent on base jump migration. Dependent packages (viem, abitype etc.) are unchanged.

2. There must be no regression in site functionality.

   No apparent regressions unless the hardhat error in gnar-contracts persists in Vercel.

Without thorough tests in place, the peer/sub dependency graph is basically a turtles all the way down rabbit hole so testing in a Vercel temp build is the best way to test this update.

5. Build and run steps remain simple and consistent with the README.

Possible .graphclient errors upon runing pnpm run build:graphclient manually. Need to test running manually on current gnars-dao:main to determine if this is a regression. The webapp build runs successfully with the current .graphclient.

pnpm run wagmi:generate rebuild works without errors.

No build config changes were made.

7. The site is builds and deploys on Vercel.

   Awaiting deploy authorization to see if there are any build errors (logs). If hardhat block number build config error persists in Vercel. That can be addressed.

[asmattic]

All non wagmi related packages updated to next major versions.

[asmattic]

Not sure exactly where the hardhat error is originating, if it just needs the .env keys in Vercel but the webapp builds without errors locally.

[asmattic]

[mulfdev]

yeah no worries, as long as web builds we're good. will review today

[asmattic]

All added formatting unrelated to PR removed. Local webapp build confirmed still working.

[asmattic]

Removed .npmrc files. Kept node@v18.20.2 (see comments). Tested local webapp builds with all other changes requested.

[mulfdev]

Also let's rebase off the most recent merge

[asmattic]

After looking again it looks like you ran asmattic/main locally and not asmattic/package-updates which is the branch for this PR.

• Can you send the build logs/errors that showed up in the Vercel preview deployment?

[mulfdev]

Vercel preview is only for the given branch. Didnt see the branch change, let's limit that in the future or close and open a new pr.

[asmattic]

Vercel preview is only for the given branch. Didnt see the branch change, let's limit that in the future or close and open a new pr.

I'll make sure to have main as the comparison fork branch for future PR's. In the interest of not creating a 3rd PR for this issue I think we should wrap up this issue here.

I just need preview build logs to locate and debug the cause of the webapp build error produced.

[mulfdev]

for commit hash ae732f9

the vercel logs dont reveal anything here that wasnt determinable on local?

[asmattic]

ae732f9

Thanks, I'll debug from there and try and replicate locally. I'll request re-review when I have tracked down the root cause.

[asmattic]

Dependency connectkit@^1.5.1 was pulling in connectkit@1.7.x (see breaking changes here)[https://docs.family.co/connectkit/migration-guide#section-170-breaking-changes-update-packages] which requires wagmi@v2. The alchemyId error was an artifact of the wagmi@v2 larger upgrade due to the connectkit relation.

Replicated the alchemyId type error removing pnpm-lock.yaml in root and running pnpm install and build in webapp below where you can see the connectkit breaking version.

Fixing connectkit to v1.5.1 resolves this issue and runs a successful build. I'll avoid post another local build screenshot, lol.

I'm pretty confident if another build error occurs, it'll at least be a new one.

[mulfdev]

🔥