Request from @nestorbonilla on KERNEL video call

Is your feature request related to a problem? Please describe.

Currently all versions of CEA pull the top commit from the branch set in constants.ts. This leads to some issues in so far as if someone has installed create-eth-app globally rather than using yarn create eth-app the templates they install may not be compatible with the version of CEA they have. (This may not be the recommended way of using CEA but I imagine someone out there is.)

It also means that should a broken commit make its way into the dev branch, it's instantly live and causing problems. We also need to juggle the branch variable between staging and develop and it introduces the possibility of the npm package tracking the staging branch by accident.

Describe the solution you'd like

If we use the url format https://github.com/paulrberg/create-eth-app/tarball/<PACKAGE_VERSION> in templates.ts then yarn create eth-app will always pull the commit at the time of the last push to NPM using the version as stored in package.json.

We could then have the branch based downloading of templates purely as a development tool behind an environment variable.

Tailwind is a utility first framework that allows you to stop writing custom css and rules and classnames.

Think bootstrap or material but without the prescriptive design implementation. Just a modular shorthand syntax for common css rules.

An argument could be made to not add this as it’s certainly not ubiquitous like typescript yet, but everyone (including dev thought leaders on twitter) that uses it seems to agree it is a game changer once you build up the muscle memory of the syntax.

Being able to copy pasta markup and styles in one go without needing to build an inheritance chain of styles saves a ton of time.

Much like JSX early on, you have to suspend your disbelief and just try it for a week straight, and then it clicks.

A good CLI tool should have a proper README file, serving as the de-facto documentation.

Here's how create-react-app does it.

If #63 gets merged, it will create a precedent for CEA accepting diverging templates across the UI frameworks. To the end user, the experience is not altered much, but this becomes a tracking nightmare for us - what features are in the React side of the codebase, what features aren't, and ditto for Vue.js.

We should either (1) strive to keep the templates as similar as possible across the UI frameworks or (2) make a concession and give up on Vue.js, to keep development lean in the v1.x releases.

Happens on f95bcc:

I like to make "develop" the default branch in most of my version-controlled projects, but in the case of CEA, it would make more sense if we used a better name that would indicate production-readiness.

I'd go with "main", as per GitHub's latest migration from "master".

As mentioned in #61, we have two copies of ipfs.js. If we're going to be adding extra helper scripts in future it's worth creating a single folder to store them in.

A data server is not an ancillary component for many Ethereum apps, so we should reconsider whether including this in the default template makes sense.

We can keep this feature but make it opt-in via a boolean flag, i.e. --subgraph.

Create Eth App is powerful - it lets you choose-your-own-adventure via the --framework and --template CLI arguments. However, these options are not allowed when running Create Eth App with no arguments, i.e. yarn create eth-app or create-eth-app. Should we ask the user about them?

This is meant to be a discussion, since I'm not yet sure if the payoff is worth it.

https://github.com/PaulRBerg/create-eth-app/blob/c71f66d47c844e1182bf73d3d82979c33b36a6c1/handlebars/react/packages/react-app/package.json.hbs#L39

I've just spotted that we're installing typescript in all templates. This looks like it's just adding to the install time for no benefit as it isn't being used (although people should).

See Release v4.0.0.

As suggested by Moody Salem via Twitter:

@TomAFrench I think you said you'll be working on this as per the splitting of Scaffold Eth into different packages.

Possible candidates:

• Web3 React
• Web3Modal (Formerly Web3Connect)
• Blocknative's Onboard.js

The last one has a particularly impressive feature: it monitors the mempool so it lets developers know when the end-user overrides an Ethereum transaction with one with a higher gas price (but same nonce). Not sure how useful this is for Ethereum beginners though, or other people interested to bootstrap a new Ethereum-powered frontend app.

WalletConnet currently crashes without a valid Infura id.

We should substitute the hardcoded Infura id with an environment variable and make Web3Modal not crash when the id is not set (ergo when booting a create-eth-app project).

This is related to the HEAD commit on the staging branch, not on develop.

The @project-name/react-app package depends on its corresponding @project-name/contracts package, but the latter is not listed in the former's "dependency" list.

Refer to this Twitter discussion for context.

Conflicts:

• The CEA templates use JavaScript, whereas HQ20 uses TypeScript
• CEA focuses on UI only, whereas HQ20 also contains smart contracts

Nothing that can't be solved via a productive evening of refactoring though.

When the install scripts executed successfully, we should welcome the user in a cheerful way.

Maybe "Hello from Create Eth App! Run yarn react-app:start to start development".

We should consider using emojis.

For each new DeFi template, the repo grows twice as much as in size because the ABIs and the addresses are duplicated across the UI frameworks.

We should build a template of templates of templates (not kidding), whereby the contract ABIs and the address are pulled out each template source files, and the logic code maps each template to its corresponding contracts (to be specific, the logic code in template.ts).

Bug Description
Got an error:

error [email protected]: The engine "node" is incompatible with this module. Expected version "^8.10.0 || ^10.13.0 || >=11.10.1".
error Found incompatible module

Steps to Reproduce

Just run the command

Additional Context
MacBook, macOS 10.15.3

Bug Description
error An unexpected error occurred: "https://registry.yarnpkg.com/mdncomp/-/mdncomp-1.13.1-alpha.tgz: Request failed "404 Not Found"".

Steps to Reproduce

1. yarn create eth-app my-eth-app

Expected Behavior
folder created

Additional Context
node -v : v10.16.0
yarn -v: 1.21.1

We should probably just stick with the defaults and launch CEA asap, but if there's any command that makes no sense at all, we should nuke it out from orbit.

It's not a nice user experience to see all these warnings while spinning up a new project with create-eth-app:

Justin (CTO of Synthetix):

In its early days, I was somewhat adamant to keep Create Eth App a frontend-only development tool. However, with time, interesting use cases for smart contract development came to mind: flash loans, buidler setups, etc.

I'm still not convinced that it is worth it, particularly given the complexity it would bring, but I decided to open the GitHub issue to entertain the idea further.

Similar to money-legos:

Bug Description

Trying to install create-eth-app on Windows [Version 10.0.18362.720]
workspaces are set default since yarn 1.0.0
still the error occured so tried recommended command and tried to install again

-yarn config set workspaces-experimental true

still error occurs

following error

C:\Users\lazypuppet\mk1>yarn create eth-app my-eth-app
yarn create v1.22.4
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Installed "[email protected]" with binaries:
      - create-eth-app
The Yarn Workspaces feature is necessary for Create Eth App. Please enable it by running this command:

  yarn config set workspaces-experimental true
error Command failed.
Exit code: 1
Command: C:\Users\lazypuppet\AppData\Local\Yarn\bin\create-eth-app
Arguments: my-eth-app
Directory: C:\Users\lazypuppet\mk1
Output:

info Visit https://yarnpkg.com/en/docs/cli/create for documentation about this command.

Steps to Reproduce

1. using shorthand yarn create eth-app my-eth-app

Expected Behavior
create-eth-app should have been installed and my-eth-app should be created

version
Windows [Version 10.0.18362.720]
Node.js v12.14.1
yarn version v1.22.4

Before yarn 1.0, the workspaces feature was not activated by default. Users had to manually activate it by running this:

yarn config set workspaces-experimental true

Therefore, before claiming that the create-eth-app install script succeeded, we should verify that this config is set to true.

Here's the full output after running yarn run build:

$ ncc build ./src/index.ts --out dist/
ncc: Version 0.21.1
ncc: Compiling file index.js
ncc: Using [email protected] (local user-provided)
(node:89588) DeprecationWarning: Compilation.modules was changed from Array to Set (using Array method 'reduce' is deprecated)

Tslint is getting deprecated.

Since v1.1.0 of CEA has been originally published in February, Compound launched the final phase of their protocol. This includes the new COMP token and other governance modules that are not currently part of CEA's Compound template.

https://github.com/PaulRBerg/create-eth-app/blob/c71f66d47c844e1182bf73d3d82979c33b36a6c1/handlebars/react/packages/react-app/package.json.hbs#L33

On the topic of #41, shall we include a cookie cutter eslint config with each template? This shouldn't be over the top in terms of strictness but enough to hopefully form good habits (indentation, semicolons, etc).

Otherwise we should probably remove this as well.

We should have a minimal FAQ Page, similar to faq.sablier.finance. This could also help with making the READMEs smaller and easier to maintain.

Lots of things could be included there: why yarn and not npm, how the subgraph works, how to deploy to IPFS or Vercel, etc.

Finding a testnet faucet that works can be a pain, especially when you're new to Ethereum and you don't know the basics.

Giving users an easy way to get testnet ETH or DAI would be nice. Bonus points if we convince the miners running the testnets to sponsor us and make CEA a faucet in its own right.

This repository as of now is a glorified fork of create-next-app. We should modify their source code and replace it with whatever it's needed for create-eth-app.

Requested by Prodoggy on Reddit.

I noticed that #58 adds two files to the codebase that are almost the same except for one line where React uses "build" and Vue.js uses "dist".

I don't think there's any benefit in keeping different names for the build folder of the app.

As explained here, the problem with the current design of the templates in CEA is that the same code can be found in A LOT of places.

If you look at the App.js file of each template in the templates/react folder, you'll notice a symmetry. This is because the point of a DeFI template is to provide the user with the bespoke ABIs and addresses of that specific DeFi protocol, not with different frontend functionality.

This makes for a system that is bulky, brittle and not scalable at all. The current unpacked size of this package is a whopping 878kb. But there is a solution.

We can make good use of handlebars.js (or a similar tool) to design an architecture that's basically a template of templates. There would be a handlebars template for each UI framework that each DeFi template would parse it and input its own handlebars context, producing a consumable js file that the end-user will be provided with.

I implemented a similar system in sablier-subgraph, where there's a handlebars template that I parse and give a different context for Ethereum Mainnet and the four popular testnets.

Testing is manual and laborious today. We can make it better!

I'm thinking of a couple shell scripts that execute on a CI server and runs the installation script for all possible frameworks and templates. E.g.

yarn create eth-app my-aave-app --framework react --template aave
yarn create eth-app my-compound-app --framework react --template compound
...

Is your feature request related to a problem? Please describe.
There's a ton of benefit to having predefined templates with respective ABIs but I'd like to develop my frontend with frameworks other than React, specifically Vue.

Describe the solution you'd like
When running create-eth-app one should have the ability to choose their frontend framework (perhaps by a --framework flag) which would use the respective framework's CLI to generate the project.

The main README (and some sub-READMEs) contain folder structures for the final boilerplate that users receive.

@TomAFrench, you made a few changes lately, namely the graphql queries and the IPFS work, so we have to update the READMEs.

Happens on f95bcc:

My thought was cd to react app and just do yarn add @material-ui/react

But then when I start the front, it looks for that dependency in the root directory of the app

I made this a monorepo, because I thought that we will need a copy of the contracts deployed to the subgraph. However, as per PaulRBerg/cea-template#2, we decided to move that into the end-user source code.

Should we maintain this repo as a monorepo or not?

It's nice for open-source projects to have a detailed CHANGELOG for tracking progress over time.

The current GIF has been recorded with Quicktime and it doesn't have a proper level of awesomeness. We should use terminalizer to record a smoother version, just like create-react-app did.

Just like Create React App displays the spinning React logo.

Is your feature request related to a problem? Please describe.

All of the generated packages are being given the rather generic names @package/contracts or @package/react-app.

In the case where someone is doing smart contract dev they may wish to publish packages of the solidity contracts or their artifacts for use by others. Having a meaningful package name pre-filled would be useful.

Describe the solution you'd like

For now we could pull the name of directory in which create-eth-app is building the project in and injecting it to take the place of @project. e.g. create eth-app my-eth-app will result in packages with names such as @my-eth-app/contracts

Some preprocessing would need to be done to ensure it results in a legal package name.

Additional context

This can wait for the time being as the currently generated packages won't be being published to npm at all but it's a nice bit of polish all the same.