A place for talking about the Ethereum Virtual Machine on Farcaster.

Hi, I made a library that spins up a front-end for you to interact with your contracts while in development. The UI is generated from your compiled contract artifacts. Supports Hardhat and Foundry.

Demo: https://www.youtube.com/watch?v=s5IMzkf2uak
Package: https://www.npmjs.com/package/@type_of/contract-gui

There is a lot to unpack here. 
Literally, you committed 400+ files totaling 280+MB of .next cache to the pkg.
Also, block explorers support uploading custom ABIs you can probably make a command to auto-upload and have a UI.
IMO for contract development testing scripts are the preferred way of interaction.

Engineer on Base 🔵 • Building BlockSocks 🧦 • Denver, CO 📍

Software developer, open source enthusiast, privacy advocate.

Clear Wallet Open-source privacy focused wallet: https://clear-wallet.flashsoft.eu/


I mean, yeah, the library is a built Next.js project, so that's expected. It's meant for local development so file size shouldn't matter IMO. Also, since it's primarily for local dev, block explorers wouldn't work.

> testing scripts are the preferred way of interaction

IMO, having options is good.

No .next folder should never be included in npm pkg is meant to only exist on local dev machine. 

Use .npmignore file to ignore that folder for your next version of the pkg.

package.json -> https://github.com/dgca/web3-starter-kit/blob/main/packages/contract-gui/package.json#L20
bin script -> https://github.com/dgca/web3-starter-kit/blob/main/packages/contract-gui/bin/start-contract-gui.mjs

I could run Next.js in dev mode, but figured shipping the built app was better.

Lol, I don't think this is a yes or no thing, it's a choice. This package is the built Next.js project and a bin script to initialize the server. I chose to build the Next.js project to prioritize ease of use. I'll think about doing it differently but it's not a super high priority since the project currently works.