Structure project as `create-next-app` example

[with-heart]

This issue is a proposal for structuring the project in a way that allows it to quickly achieve its goals while providing end users with a familiar development experience. I'll start by explaining create-next-app and end with the proposal.

create-next-app

create-next-app is a CLI tool for generating Next.js projects with everything set up for you.

For example, to generate a minimal TypeScript-based Next.js project we can run yarn create next-app --typescript minimal-nextjs-project. This creates a directory with the following structure:

minimal-nextjs-project
├── next-env.d.ts
├── next.config.js
├── package.json
├── pages
│  ├── _app.tsx
│  ├── api
│  │  └── hello.ts
│  └── index.tsx
├── public
│  ├── favicon.ico
│  └── vercel.svg
├── README.md
├── styles
│  ├── globals.css
│  └── Home.module.css
├── tsconfig.json
└── yarn.lock

One of the cool features of create-next-app is that it allows a project to be generated from an "example" project using the --example flag. This can be either the name of one of the official Next.js examples or a GitHub URL.

Generating from examples

For example, to generate a Chakra UI project with TypeScript we can run yarn create next-app --example=with-chakra-ui-typescript chakra-ui-typescript-project. This creates a directory generated from examples/with-chakra-ui-typescript with the following structure:

chakra-ui-typescript-project
├── next-env.d.ts
├── package.json
├── README.md
├── src
│  ├── components
│  │  ├── Container.tsx
│  │  ├── CTA.tsx
│  │  ├── DarkModeSwitch.tsx
│  │  ├── Footer.tsx
│  │  ├── Hero.tsx
│  │  └── Main.tsx
│  ├── pages
│  │  ├── _app.tsx
│  │  ├── _document.tsx
│  │  └── index.tsx
│  └── theme.tsx
├── tsconfig.json
└── yarn.lock

As we can see, this example includes src/theme.tsx and a number of components in src/components. Additionally, the package.json file includes all of the relevant Chakra packages needed to get started with a Chakra-based Next.js project:

{
  "private": true,
  "scripts": {
    "dev": "next",
    "build": "next build",
    "start": "next start"
  },
  "dependencies": {
    "@chakra-ui/icons": "^1.0.5",
    "@chakra-ui/react": "^1.4.2",
    "@chakra-ui/theme-tools": "1.1.2",
    "@emotion/react": "11.1.5",
    "@emotion/styled": "11.1.5",
    "framer-motion": "^4.0.3",
    "next": "latest",
    "react": "^17.0.2",
    "react-dom": "^17.0.2"
  },
  "devDependencies": {
    "@types/node": "^14.6.0",
    "@types/react": "^17.0.3",
    "@types/react-dom": "^17.0.3",
    "typescript": "4.3.2"
  }
}

Generating from GitHub URL

Similar to the above and related to this proposal is the ability to generate from a GitHub URL (and, optionally, a specific path within that repo).

As an example of this feature, we could generate the same project as above using the Next.js GitHub URL and path: yarn create next-app --example=https://github.com/vercel/next.js --path=examples/with-chakra-ui-typescript

Another example, assuming we go this route, is generating a project from this very repo: yarn create next-app --example=https://github.com/developer-dao/create-dao

Proposal

Structuring this repo (or a subfolder in it) as a Next.js example would allow us to utilize create-next-app as part of our CLI tool to generate a project for the user and leave them with a fully-featured and familiar development environment.

The repo/subfolder would contain folders for the smart contract, Next.js frontend, the README.md file, and a package.json that includes all of the required dependencies like hardhat, Chakra, etc. and any scripts we want to define for the user to have access to.

The CLI would defer to create-next-app (passing --example and possibly --example-path which points to the create-dao repo+path) as its first step in order to generate the project locally for the user. If there are additional steps required for initial setup related to the contract, hardhat, or anything else really, we can handle those by having the CLI then cd into the new directory and run setup commands from there.

With this setup, if we publish the CLI package as create-dao, a user could run yarn create dao <directory> and the project would be generated for them in the specified directory with everything they need to get started.

Benefits

• User ends up with a project that matches the structure we define in our repo.
• We're able to configure scripts and dependencies for the user's project.
• Minimal effort on our part to launch as we only have to create the project we want the user to end up with and then create a CLI wrapper around create-next-app to get it to them + set it up.

[rheinardkorf]

@with-heart , I am just curious, are you proposing we use NextJS as the FE framework or are you just interested in create-next-app 's scaffolding ability?

If you are proposing NextJS as the Framework then I have some minor concerns. I love NextJS, its really nice and easy to work with, but when it gets to deployment we might run into some concerns. Any of the SSR related code needs by definition a server. Is this something that we're considering here?

Where and how are we expecting users of create-dao to deploy their UI? Vercel, Netlify or perhaps completely static hosted anywhere, e.g. S3 with/without Cloudfront?

Deployment is always one of my biggest concerns. Everything works nice local, until you need to put it somewhere.

[Dhaiwat10]

@with-heart this is a great proposal. Was wondering if it was possible to create an example of our own for create-next-app? Asking since we want to have some custom boilerplate specific to DAOs there.

[Dhaiwat10]

ffs Clicked the wrong button

[henripal]

@with-heart thanks so much for the detailed and incredibly well motivated proposal, it makes a ton of sense I think. @rheinardkorf since this is for other, future DAOs, the (future) users of create-dao would have to figure out serving themselves @Dhaiwat10 yes, we can create our own template and use it with create-next-app, see #4

[with-heart]

@rheinardkorf since this is for other, future DAOs, the (future) users of create-dao would have to figure out serving themselves

Yeah I definitely understand the concern @rheinardkorf but I think it's more of an end-user concern. We're giving them everything they need to get started with their site, and we can do it in a way that allows them to make those kinds of decisions for themselves.

[Dhaiwat10]

Closing via #17