Consider removing truffle-contract dependency

[frangio]

It might be better if the helpers were agnostic to the framework that is being used, and used web3.js directly.

[nventuro]

With #38 merged, the only truffle dependency is on truffle-contract.

[frangio]

The uses of truffle-contract that we're aware of are:

1. expectEvent uses decodeLogs;
2. singletons returns truffle-contract instances.

[nventuro]

expectEvent.inConstruction also relies on transactionHash, which returns the transaction in which a contract was created.

[cnasikas]

I also firmly believe that OpenZeppelin helpers should be agnostic to truffle. To bypass the dependency of decodeLogs I use:

const txEventsToLogs = events => {
  return Object.keys(events).map(event => ({
    event,
    args: events[event].returnValues,
    ...events[event]
  }))
}

expectEvent.inLogs(txEventsToLogs(tx.events), eventName, eventArgs)

Be aware that the event returned object of web3 does not have args member but returnValues

[nventuro]

To avoid dropping truffle support altogether, we can have expectEvent receive the raw object returned by truffle contracts or web3 contracts, detect which type we got and act accordingly.

But how should we handle the instances singleton returns? Creating a truffle-contract from a web3 contract is not trivial. A couple options:

1. just return the address and ABI, let the user create the object themselves
2. provide helpers to convert a web3 contract into a truffle contract
3. provide methods that return either a web3 contract or a truffle contract

[frangio]

Option 4 is to make it configurable (library-wide), with any function (address, abi) => Contract.

The current configurability "system" is not very good though because you can only configure once, and it results in weird usability.

[nventuro]

I like it! We'll probably keep the configuring of the web3 instance (specially with truffle no longer being the default), so having this makes a lot of sense. I'll review the config system to make it more flexible.

[frangio]

We'll probably keep the configuring of the web3 instance

I think this should be changed to configuring the provider instead of the entire web3 instance. We should control internally what version of web3 we're using. But that can be done as a separate change.