I followed the doc you wrote. But when I tried to change the minting price in ExampleNFT.sol from 0.1 to 0.01 ether, I ran the http://deploy.sh it only gives me "Using goerli contract address: 0xe584409f2ba1ade9895485d90587fd46baa3c0d8" over and over again, even if I tried to write a new contract. I had set up the local env.

(Thanks to the reply from @TheRightChoyce: I need to delete the packages/contracts/deploys/goerli/ExampleNFT.json and run the ./deploy.sh in packages/contracts to deploy a new contract before trying to redeploy the new contract, otherwise the shell script will exit and just print the existing contact info. Now I can deploy new contracts. Thanks to him)

NPM package exploits are a common vulnerability for web3 apps. While we can't eliminate this risk for implementors, we can take some steps to reduce it. These steps could include:

• Dependabot integration for security advisories
• Audit CI integration for security advisories
• Restrict preinstall and postinstall with LavaMoat (background here) – although LavaMoat may be unnecessary here since pnpm supports this out of the box
• Pin packages to specific versions

Consider moving to Prettier -> eslint, rather than eslint -> Prettier. This will make it easier to autoformat things that eslint doesn't support but prettier does (CSS, SVG, HTML, etc.)

• Run through setup process and write a setup guide
• Move common eslint stuff for TS to root or subpackage
• Compile TS for imported packages (just contracts for now I think?) and rip out the webpack TS build step. This should make it easier to replace Next.js with something else.
• Consider moving to Prettier -> eslint, rather than eslint -> Prettier. This will make it easier to autoformat things that eslint doesn't support but prettier does (CSS, SVG, HTML, etc.)
• Make sure packages put files in the right place (e.g. contracts ABI -> subgraph ABI) or can generate their own from dependency/import
• Consider removing/ignoring contracts artifacts and typechain-types

Slither support would be nice to have for the contracts package. It's compatible with Forge as of earlier this year.

Once Vercel supports Node 16, we should move to that + add -y option: #3

vercel/community#37

It'd be nice if writing gql would be type checked/give hints (I think Stripe had this)

not sure this will be always needed in the default setup and the codegen is kinda clunky, esp if it breaks/is pointed at the wrong thing, and this may become more apparent once the hosted subgraph is taken offline

Just needs a branch name change from master to main

Something similar to powerlevel9k where you use a shell script to set up your bash prompt.

I think there are a few config options that would be cool to have in particular, and set up your scaffold in the way you prefer through running the script. It starts as something very vanilla if the script is never run.

This might defeat the purpose of the opinionated scaffold, but gives more flexibility for everyone to use IMO.

Init

Set your package names in all the package.json files

Package Manager

• pnpm (default)
• yarn + lerna?
• npm + lerna

Wallet Connect Options

• RainbowKit/Wagmi (default)
• useWallet/web3modal

GraphQL Options

• urql (default)
• swr + graphql-request

Editor Options
(multi-select)

• prettier (default)
• eslint (default)

CSS Options

• Tailwind (default)
• Vanilla
• etc

Also I'm happy to start on this after I get a few things done

It was web3-dapp-scaffold, then web3-app-scaffold (because I didn't feel right calling it a decentralized app), and now web3-scaffold.

I'm not a massive fan of the "scaffold" word, feels a little obscure, borrowed from Ruby(?), and probably hurts word of mouth long term?

Maybe create-web3-app?

Super sorry for the beginners question, but is there a quick start for installing all parts of the repo?
Something like
Install packages

pnpm install

Installing and Deploying contracts

cd packages/contracts
yarn compile

Install and deploy subgraph

cd packages/subgraph
yarn build
yarn deploy:goerli

Install and deploy frontend

cd packages/app
npm run dev

Spent too long fighting these! Worst case we use --no-git during install and check in ~all the files. Ideally we'd be able to just lean on pnpm since we're using it already to generate types, manage the monorepo, etc.

foundry-rs/foundry#1847

port over from AFD

I encountered an uncaught exception in my Next.js API route. The error message I received was:

// 500 Internal Server Error

Uncaught Exception 	{"errorType":"Error","errorMessage":"Unexpected server response: 400","stack":["Error: Unexpected server response: 400","    at ClientRequest.<anonymous> (/var/task/node_modules/.pnpm/ws@7.4.6/node_modules/ws/lib/websocket.js:604:7)","    at ClientRequest.emit (node:events:513:28)","    at HTTPParser.parserOnIncomingClient [as onIncoming] (node:_http_client:693:27)","    at HTTPParser.parserOnHeadersComplete (node:_http_common:128:17)","    at TLSSocket.socketOnData (node:_http_client:534:22)","    at TLSSocket.emit (node:events:513:28)","    at addChunk (node:internal/streams/readable:315:12)","    at readableAddChunk (node:internal/streams/readable:289:9)","    at TLSSocket.Readable.push (node:internal/streams/readable:228:10)","    at TLSWrap.onStreamRead (node:internal/stream_base_commons:190:23)"]}
Unknown application error occurred
Runtime.Unknown

I've tried adding additional error handling code to my API route, but I'm still experiencing this issue: route handler

I implemented the same routes in a new nextjs app and it work perfectly: new route handler

See convo here: #26 (comment)

It doesn't look like there's an existing eslint rule for this, but there's some code here which we may be able to incorporate as a custom rule: jsx-eslint/eslint-plugin-react#2888

For more on why we want to avoid this pattern, see here: https://kentcdodds.com/blog/use-ternaries-rather-than-and-and-in-jsx

https://twitter.com/smakosh/status/1628448973752000513

With the recent Solana dep chain exploit, thinking it’s important to have some sane security defaults. Not sure CSP will help in the context of extension-based wallets but it certainly can’t hurt to minimize attack surface area.

see also #44

using the pattern described here we can define a shared build.yml file that is run on workflow_call and includes our various setup steps (cloning, pnpm setup, forge install, caching, etc).

When in local dev, an error shows up if the chain doesn't support ENS. This issue stems from RainbowKit and can be tracked here rainbow-me/rainbowkit#429.

Example error:

next-dev.js?d62b:32 Error: network does not support ENS (operation="ENS", network="foundry", code=UNSUPPORTED_OPERATION, version=providers/5.5.2)

there's some new options I am using in a personal project (AFD) that have come in handy when generating output for ABI/types

to reduce time to get up and running, use cloudflare rpc instead of expecting an alchemy key

https://wagmi.sh/docs/prepare-hooks/usePrepareContractWrite

Usage is the best way we'll improve this project, but it's also worth keeping an eye on how other folks are approaching the problem. Here are a couple starters that I've wanted to check out further for ideas that we might be able to bring back to web3-scaffold.

• https://github.com/paulrberg/foundry-template
• https://github.com/Naim-Bijapure/scaffold-eth-next
• https://github.com/abigger87/femplate

These seem to be noisy in PRs. But maybe we ought to just fix all of them so that warnings in PRs are for realsies.

Makefiles run commands faster than NPM. Maybe we could add a Makefile to the contracts package? Although this might not have any benefit over running forge commands directly.

Good guide to doing this here: https://mirror.xyz/devanon.eth/RrDvKPnlD-pmpuW7hQeR5wWdVjklrpOgPCOA-PJkWFU

Getting a build error when I push next js api implementation:

ELIFECYCLE  Command failed with exit code 1.

16:59:19.472 | Error: Command "pnpm run build" exited with 1

Does this project need extra configs for api to build?

OpenZeppelin Defender? Tenderly? Both? Neither?

Someone pinged me about issues installing deps because they hadn’t yet installed forge. At the bare minimum we should have docs to suggest installing forge before using but maybe we can consider a smarter approach to installing deps?

Instead of formatting solidity with prettier