RFC 1

[tylerjohnhaden]

Decisions that I'd like to get an opinion on:

• Using truffle-config.js instead of truffle.js or both.
  • I think that accessibility to devs in Windows environments should outweigh the aesthetic choice of just truffle. Also, having two identical config files is a little unnecessary, and may lead to discrepancies.
• Using INFURA_PROJECT_ID as the canonical env name instead of INFURA_KEY.
  • Technically each Infura instance has two numbers, "project id", and "project secret". And this would be the "project id" value.
• Having "config": { "ganache": { ... } } in package.json.
  • This lets us mirror these values in the script "npm run ganache", and in truffle-config.js
  • This could be better handled if we wrote actual scripts to run ganache for testing/coverage such as in openzeppelin/test.sh
• Licensing with MIT rather than any other option.
• Having the repo public vs private/internal
• Making all node modules "dev", because this never gets packaged up for deployment.
  • This might change if we add in any CI/CD
• truffleConfig.networks.development.from do we need this?
• Using Infura "v3" hard coded.
  • I don't think it'll change very often
• Using Node v11 vs v8
  • I like the latest versions of languages, but should it be "long term supported"?
• In .soliumignore, we ignore node_modules. Maybe we should have a full auditing suite that also checks any dependencies (as this is still a burgeoning field)
• Using custom rules in .soliumrc.json
  • I used the same one as openzeppelin/.soliumrc.json
• Epic - Building a default suite of testing.
  • This could include testing deployment/gas for every deployable contract, checking if any migration constants are accurate, auto-generating mocks, etc
• Standardizing revert messages, and event names, and userdocs
  • My solution in TreasureChest was to create a yaml specification at the top of the contract. Because all "userdoc" comments are useful after compilation, it always ends up in the JSON specification.
  • On the note above, I think we should leverage the contract ".json" file to store versioning, and all compile-time information. I think managing these files better (storing remotely and versioning) would improve visibility with clients and team members. I can also write our own custom JSON/ABI->JAVA generator (because web3j wrappers are bleh).
• Using pragma solidity >=0.4.21 <0.6.0; in Migrations.sol
  • This is what comes out of the box with Truffle==v5.01
• Should test scripts be numbered? openzeppelin uses the pattern: "Foo.test.js" instead of "0_foo.js"

[misterzero]

Using truffle-config.js instead of truffle.js or both Agreed, do what is most accessible for devs in any env

Using INFURA_PROJECT_ID as the canonical env name instead of INFURA_KEY Agreed, let's use the most accurate term

Having "config": { "ganache": { ... } } in package.json Agreed, I think this will happen anyway when we start using z_OS

Licensing with MIT rather than any other option I like MIT for flexibility, but we can discuss others

Having the repo public vs private/internal I think we'll be referencing a lot of this stuff in blog posts

Making all node modules "dev" Agreed, though there will be more prod dependencies if we add frontend code

truffleConfig.networks.development.from do we need this? Needs a bit of research, probably don't need that

Using Infura "v3" hard coded Seems legit, as you said it won't change of

Using Node v11 vs v8 Have to check compatibility with truffle, OpenZeppelin, and when you find the right match I would encode it in package.json:

"engines": {
"node": "8.11.x",
"npm": "5.6.x"
}

In .soliumignore, we ignore node_modules. Maybe we should have a full auditing suite that also checks any dependencies (as this is still a burgeoning field) This could be a nice enhancement, though we won't be able to fix a lot of those issues without a lot of work on other open source projects

Using custom rules in .soliumrc.json I consider OpenZeppelin a standards-setting org, I'm good with using theirs

Epic - Building a default suite of testing These are great ideas, gas estimation would be very helpful

Standardizing revert messages, and event names, and userdocs Yes! Also your note about the contract metadata (ABI, deployed addresses) is on point, we use that stuff in web3 UI apps so it would be good to standardize how we share that. In ALF I copied it to the src/assets/ folder after truffle migration. Then if the user changes their network in MetaMask, I automatically get the correct address from the generated contract metadata.

Using pragma solidity >=0.4.21 <0.6.0; in Migrations.sol I would check any examples from OpenZeppelin

Should test scripts be numbered? openzeppelin uses the pattern: "Foo.test.js" instead of "0_foo.js" Probably not necessary, unless they need to be run in a certain order (which they shouldn't, since tests are stateless).

[misterzero]

Sorry, not sure if I was supposed to close?

[tylerjohnhaden]

This is good feedback. I'm going to implement as many as possible, and create issues around any that still need work.