tylerjohnhaden / __truffle-boilerplate Goto Github PK

See below

From RFC 1:

• 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).
• 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.

research if this makes a difference

Add a script "npm run audit". Needs research into auditing/coverage/testing etc.

From RFC 1:
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

From RFC 1:
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
• These are great ideas, gas estimation would be very helpful

This should not be the behavior if we don't need infura. For example, if we are testing locally on a non-forked ganache.

When I run npm run coverage which is just short for node_modules/.bin/solidity-coverage, I get an error:
There was a problem instrumenting ./coverageEnv/contracts/TreasureChest.sol: SyntaxError: Expected ")", ",", comment, end of line, or whitespace but "d" found. Line: 150, Column: 35

... which would be a syntax error if I wasn't using Solidity 0.5.0.

I forgot to add in "migrate:kovan" inside the "start:kovan" or "test:kovan" scripts

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"

From RFC 1:
Using pragma solidity >=0.4.21 <0.6.0; in Migrations.sol

• This is what comes out of the box with Truffle==v5.01
• I would check any examples from OpenZeppelin

It appears that when I write tests where very many contract function calls are made, only the first 16 are displayed. This is very low priority, but figured it should be documented.

This came up when I was writing some automated test generation, and the use of...

for (let i = 0; i < n; i++) {
    await myContract['myFunction' + i.toString()](myValue, { from: accounts[0] });
}

blew up the number of functions being called.