@salieflewis raised the question around using framer motion in work that is intended to be published as a package any user can install with their react project.

The question was specifically around using framer motion as a dependency to handle transitions, animations etc.

We are already assuming and specifying peer dependencies for mandatory web3 libraries, and leveraging tailwind and postcss as the default styling utility.

In general the gold standard is to keep your bundles as small as possible, reducing load times. It's preemptive optimization.

My opinion around this is to be library agnostic as much as possible when the included library introduces and api or markup that may become "black boxy" to consumers of the package... hence if this is something that could be achieved with browser native apis (like css animations / transitions) we try that first with the design intention of letting a user opt out or override with ease.

For UI components this could introduce a modular design approach where we split smaller chunks of UI into composable elements that leverage a parent provider to allow for reordering.

Prior work that inspires this approach can be seen in NFT Components

Theoretically if you can read for state change and can wrap a component with the animation library of choice api then the user can decide for themselves what addition libraries they want to introduce to their project.

Also when selecting libraries checking out info like this article Reduce Bundle Size(framer.motion) is really helpful.

@dblodorn sorry for not making the pull request directly, but line 9 of AppWrapper.tsx in the examples/nextjs (assume same for react too) should have chain.goerli as well so that the test apps are compatible with testnet. without this u cant use goerli in local dev, just burned an hour or so figuring this out

photo of where it needs to be added

Staging this for a little feedback... probably going to hold off on pushing into main for a little bit.

This next13 upgrade is actually a little tricky... next13 introduces a fair amount of new concepts to next.js Still feel it's important to move forward with the most up to date configurations / so this isn't stale.

https://beta.nextjs.org/docs/upgrade-guide#upgrading

https://nextjs.org/blog/next-13

Also - nice writeup on hydration errors: https://codingwithmanny.medium.com/understanding-hydration-errors-in-nextjs-13-with-a-web3-wallet-connection-8155c340fbd5

This PR introduces three configured examples of a package being developed in the packages directory being consumed by a sample next.js app that has been configured as a basic "web3" dapp skeleton.

Meaning there are included dependencies to emulate the baseline requirements for an Ethereum Dapp:

"@rainbow-me/rainbowkit": "^0.6.0",
"@zoralabs/nft-hooks": "^1.1.9",
"@zoralabs/zdk": "^2.1.8",
"ethers": "^5.7.1",
"next": "^12.3.0",
"react": "^18.2.0",
"react-dom": "^18.2.0",
"swr": "^1.3.0",
"wagmi": "^0.6.6"

Changesets Cli has also been integrated for the publishing step, this enforces keep a change log and assists with semantic versioning.

I've followed this guide somewhat, most specifically for setting up changesets. https://monorepo.guide/getting-started

One small issue that is most likely related to react 18+ / next.js 12 + has arisen around ssr hydration errors. Not fatal - but annoying, and forces the question around optimization for react 18 - and how much additional research and work that entails.

WIP Video: https://www.loom.com/share/e73dc50a1c634221b3e7a8f77a49be65

This upgrade is a little tricky... next13 introduces a fair amount of new concepts to next.js Still feel it's important to move forward with the most up to date configurations / so this isn't stale.

https://beta.nextjs.org/docs/upgrade-guide#upgrading

https://nextjs.org/blog/next-13

Also - nice writeup on hydration errors: https://codingwithmanny.medium.com/understanding-hydration-errors-in-nextjs-13-with-a-web3-wallet-connection-8155c340fbd5

Yarn config updates

TLDR Spent a bunch of time messing around with yarn 2/3 but just ended up modifying the yarn config a little and adding a clean command - and slipped an edit to the changesets config defaulting the access property to public https://github.com/changesets/changesets/issues/503

☠️ Upgrading to yarn 3 notes--- 🥴

Ok so the new version of Yarn (yarn >3.X) is kinda hellish and has introduced numerous bugs tracing into dependencies of dependencies. Bottom line it seems like a lot of work to get everything working correctly and the older version of yarn just works... seemingly for most everyone using it, and that's better for a template which is meant to be an easy starting point.

I'm going to revert back to a stable setup...

just a pile of errors like this - that were not an issue with older version of yarn:

Initial motivation to upgrade was the excitment around using @yarnpkg/plugin-workspace-tools - this resulted in needed to upgrade the version of yarn i was using to a version that supported yarn plugins: https://yarnpkg.com/features/plugins

Some links collected from this rabbit hole 🕳:

https://yarnpkg.com/getting-started/migration https://github.com/yarnpkg/berry/issues/454 https://yarnpkg.com/api/modules/plugin_workspace_tools.html https://dev.to/arcanis/yarn-3-0-performances-esbuild-better-patches-e07 https://github.com/parcel-bundler/parcel/issues/7697 https://yarnpkg.com/getting-started/qa#which-files-should-be-gitignored https://www.digitalocean.com/community/tutorials/how-to-install-and-use-the-yarn-package-manager-for-node-js https://semaphoreci.com/blog/javascript-monorepos-yarn-workspaces https://twitter.com/arcanis/status/1301151739375161344?lang=en https://stackoverflow.com/questions/71747609/how-to-specify-packagemanager-in-package-json

When I pulled this down, I was getting the error "Workspaces can only be enabled in private projects." when trying to install yarn. I ended up adding "private" : true, to the package.json file that exists outside of the app workspace. That seemed to fix things.

This will clean up the code, formatting with prettier before it is committed, and block unsafe code from being committed.

Adds:

• https://eslint.org/
• https://github.com/tailwindlabs/prettier-plugin-tailwindcss
• https://www.npmjs.com/package/@zoralabs/eslint-config

@dblodorn Feedback post completing this speedrun tutorial video: https://www.loom.com/share/2eb3b86c9c304fdc80fb6699b4bf6891

React dep issue upon package consumption:

• ran into same issue (skip to 21:10 of the loom video) where the package installed component wouldnt render in a test consumption app because "react could not be found" in the component. ended up solving this by adding in an unused import + reference to react, but really confused why that works (see below for what I did to fix it). Would love to get a better understanding of what is causing this problem, plus how to avoid (theres no way adding an unused react reference is what I should be doing???) in the future

Potential Pull Requests

-currently .changeset/config.json “access” needs to be updated to public to allow the npm package publish to go through. would be nice to have this set correctly out the gate (correct set up below)

-something that makes it so we dont have to manually copy paste the “files” : “[/dist]” reference into the package.json of the package we are publishing (code reference below)

Misc

• when I create a template repo using the create template button on github, it creates the repo in my personal repository rather than in public assembly. not sure how to get it to be created as a new public assembly repo ?? EDIT: ok im stupid you can assign the owner of the repo upon fork, so I can just set this to public-assembly. all set !

This pull request introduces a vanilla react testing environment to the monorepo.

motivation: add a less strict development environment in that you will not have to be as careful around SSR issues that are present with the combination of React 18 & Next.js 12+

Also have included some updates to documentation.

These additions should be ample for a first cut of the template repo.

It's a bit cumbersome getting through renaming the package, updating references, installing dependencies and then publishing to vercel.

vercel does not pick up on the framework and autofills the build command with something that results in a build error.

Maybe there's some sort of setup script that could be added.

Would be nice to have the option and an example of storybook usage to preview UI components.

Storybook

This Article: Why build UIs in isolation frames the approach nicely.