Deduplicate code

[schemar]

Organization and UtilityToken contracts are used in more than one repositories.
All repositories have its own implementations, so

• Its code duplication
• It is difficult to maintain code across the repositories.

Following are the items that we are trying to achieve in this epic

1. The code will be moved to a new repository.

• openst/organization-contracts already exists.
• A new repository will be created for utility token contracts.

2. These repositories should include the contract interacts

These repositories should auto-generate the contract interact code from the ABI JSON files.
Contract interacts creation in type-script has a lot of boilerplate code and its time consuming to maintain it manually. It will be helpful to consume APIs with proper typed parameters.

So for the creation of contract interacts the proposal will be as follows

• Do research on ABI to typescript generators
• Analyze if we can use any one of the existing generators that best fit our requirements, or we need to manually write the code.
• Analyze if the unit tests are needed.

Few example of generators are given below (You may add more)

• Typechain (this looks interesting)
• Soltsice.
• @0xproject/abi-gen. (this looks interesting)
• Go-ethereum has a CLI tool called abigen -> Go/Java/Objective-C wrapper. (Just for reference)

3. Publish NPM package
While publishing the NPM package

• The contract interacts should be autogenerated before publishing and should be exported.

4. Use git submodule to use the contracts in the dependent repository

• OpenST/openst-contracts
• OpenST/mosaic-contracts
• OpenST/brandedtoken-contracts

5. Update dependent repositories to use published NPM module.

[jasonklein]

@schemar: truffle documentation indicates it supports using contracts via NPM packages (I have not yet tried it, so this is a suggestion and not a recommendation 😅). Might that be a viable alternative to git-submodules?

cc: @deepesh-kn

[schemar]

@schemar: truffle documentation indicates it supports using contracts via NPM packages (I have not yet tried it, so this is a suggestion and not a recommendation 😅). Might that be a viable alternative to git-submodules?

cc: @deepesh-kn

Definitely. I think @pgev was in favor of git submodules over dependencies. @pgev can you please re-iterate?

[schemar]

I'll put step 1 on the backlog: use https://github.com/openst/organization-contracts/ and https://github.com/openst/utilitytoken-contracts

/cc @benjaminbollen @deepesh-kn

[schemar]

Will also add to use dependencies instead of copy/pasting code where possible for external things like EIP20Token.

[jasonklein]

@deepesh-kn / @schemar: where will SafeMath.sol come from for git-submodules tickets mosaic-contracts 712, openst-contracts 197, and brandedtoken-contracts 166?

cc: @benjaminbollen

[schemar]

I would guess https://github.com/OpenZeppelin/openzeppelin-solidity/blob/v2.2.0/contracts/math/SafeMath.sol

[deepesh-kn]

@schemar: truffle documentation indicates it supports using contracts via NPM packages (I have not yet tried it, so this is a suggestion and not a recommendation 😅). Might that be a viable alternative to git-submodules?

cc: @deepesh-kn

Agree, we can discuss this. We can opt for NPM as well. @pgev has used git-submodules in one of the repo. Would like to hear from him on this.

[jasonklein]

Looking more into the topic of git-submodules to resolve an open question related to organization-contracts, in addition to internet comparisons commentary that mostly focuses on costs and not benefits, the Git also appears to vote in favor of an alternative solution for our purposes:

It’s quite likely that if you’re using submodules, you’re doing so because you really want to work on the code in the submodule at the same time as you’re working on the code in the main project (or across several submodules). Otherwise you would probably instead be using a simpler dependency management system (such as Maven or Rubygems).

My understanding is that we do not intend to make changes in the submodules. Git recommends using another tool in that case.

[deepesh-kn]

Following is the conclusion from today's discussion.

• for "internal" dependencies, (explicitly now organization-contracts and utilitytoken-contracts), we use git-submodule to include the code
• for external dependencies, like SafeMath we use NPM