Colony Starter architecture requests

colonystarter
#1

Hi, @ryanchristo. I have been migrating my app-in-progress to layer on top of Colony Starter so that I can stay up to date with colony more easily, without having to manage all the dependencies, etc. myself. It’s generally going ok but i have two requests:

Is it possible to move the colonyNetwork code outside of the src folder? Generally the src folder is for code that is specifically a part of an app, not a dependency of an app. Having it in the src folder affects code lookup and other things and can slow down operation of a code editor/IDE like VSCode.

Of course you could just move it to another folder outside of src, but for long term viability and usefulness you may want to look into turning it into a npm installed package itself. Two examples of other CLIs that do this are:

  • Vue-cli (an awesome, very well designed cli tool), has a component called vue-cli-service that handles various commands that are needed. You could create a colony-cli-service that handled things like starting ganache and trufflepig, etc. It is described here: https://cli.vuejs.org/guide/cli-service.html#using-the-binary
  • Zeppelin OS has its use zos cli, which I am also using as a part of my project because I like their upgradeable contract system: https://github.com/zeppelinos/zos

I hope we reach a point some time soon where there is one cli that works with all contract libraries and packages that are needed, but we are definitely not there yet. :slight_smile:

Is it possible to anticipate that users of Colony Starter will want to make and deploy their own additional contracts on top or along side Colony? If you could set up Colony Starter with the assumption that people will be adding more contracts and deploying them with Truffle or Zos that would be great. I have added what I need for now, but that has involved installing two versions of Truffle, for example. It would be great if only one install of Truffle, etc. was needed.

Thanks for considering these things that will make Colony Starter a richer tool for a wider range of developers.

2 Likes
#2

Hey @bmiller59!

Yes, done. https://github.com/JoinColony/colonyStarter/pull/63 and new versions published.

Not sure how this got overlooked for so long. The path of the colonyNetwork submodules in each package have been changed to a lib directory outside of the src directory.

I really like the idea of having a service package that would handle things like starting and running ganache and trufflepig and I gave some thought to a similar idea awhile back but decided for now that each package would act like a boilerplate and autonomous of the colonyStarter CLI. I would be interested in revisiting the idea.

Would you mind creating an issue in the colonyStarter repo with a brief summary of this idea so that I can come back to it when I have a little more time on my hands? Maybe you can help me build it?

Yes. I have thought about creating a separate package that would be focused on developing contracts alongside the colonyNetwork contracts, one that would be less focused on colonyJS itself and more focused on developing extensions to the colonyNetwork contracts.

At the moment, if someone wanted to develop their own contracts alongside the colonyNetwork smart contracts that could be used within one of the colonyStarter projects, I would recommend creating a separate repository for those contracts and then adding the repository as a submodule that would live in the ‘lib’ directory alongside the colonyNetwork submodule.

The colonyStarter packages right now are focused on using colonyJS and I would love to create packages in the future that are more focused on developing contracts alongside the colonyNetwork contracts. In order to avoid making the current packages too complex, I think packages focused on developing smart contracts should live within their own packages, which would help keep things modular and avoid adding too much complexity to the current packages that are focused on using colonyJS and building dApps.

1 Like
#3

Thanks, Ryan! I appreciate the quick response on the lib location.

Also, I will create ticket for the service idea. I’m open to working on it as time allows. Let’s stick a pin in it for now. :slight_smile:

It could be fine by me if there were a Colony Starter option that was meant for people who wanted to augment with additional contracts. I see a hierarchy something like this:

  • Colony Basic (just core level, like it is now)
  • React Starter (similar to now)
  • Contract Starter (could be based off of Colony Basic or React Starter and be set up for contract writing/testing/etc)

With something like that you can keep the starters simple for those who want that but allow others to step into more complex dapp development that may require additional contracts.

You may remember I have proposed a few feature additions to Colony in the forum that I need need which do not seem to be priorities for the moment. That is understandable. But I would encourage you to make it easy for for people to build more complex dapps that may require additional contracts. If those contract extensions are not going to be added to Colony, then that would be the second best solution.

I do think it needs to be complicated. It’s mostly just exposing truffle and ganache, etc at the top level so that the dapps can leverage the same contract writing/deploying infrastructure that colonyNetwork is already using.

Thanks again.

1 Like
#4

As mentioned in another post, I have made a number of updates to colonyStarter and would love your feedback. I also went ahead and created colonyStarter#87 to implement your idea about a contract starter.

Thank you for the ideas and feedback!

#5

Hi, @ryanchristo ! Just had a chance to try out the new colony-cli. It’s awesome! A great step forward, thanks. (Also the bug I was having last week was nowhere to be seen. :wink:

I love how clean the package dependencies and folder structure are now: No need for lots of separate dependencies, no need for git submodules, etc. Perfect!

I am looking forward to the contract starter. It will be nice to have a clean/integrated and upgradeable way to leverage truffle and other dependencies from the colony-cli service for my own contract development.

Here’s a couple ideas for the contract starter:

A) One thing it would be nice for you to include either in the contract starter or in a contract example boilerplate are some examples of ways of interfacing with the existing colony contract infrastructure at the contract level.

For example, if I want to check if an account is a Colony Admin before allowing it to do something on my new supplemental contract. (This is something I actually need to do). And more generally, recommended ways to allow a new contract to call other colony network and colony methods.

B) Another major ongoing pain point I have is updating the references to the Colony EtherRouter address after each new yarn deploy-contracts, because that changes the EtherRouter address, and I need that address to interact with colony. When it changes, I then need to update my contracts to point to that new address and re-deploy them.

It would be super fantastic to remove that annoyance by allowing the contract starter to automatically know where to find the EtherRouter and interface with it without having to cut and paste its address into my contracts after each new migration/deployment of colony contracts.

Please keep me posted. Thanks again for everything.

1 Like
#6

Hey @bmiller59! Very happy to hear your feedback!

Thanks for trying out the new colony-cli package and providing some ideas for the contract starter/example. I will start on the contract starter/example sometime next week with your ideas in mind.

I’ll be sure to keep you posted. Thanks again.

#7

I just wanted to follow up and let you know I published a colony-starter-contract package:

#8

This is great start, thanks Ryan! I appreciate how clean the package.json dependencies are and the example contract extension.

I upgraded the colony-cli in my project and was going to start invoking truffle through the colony service but I ran into a problem. It seems that truffle options are not recognized and are not being passed through to truffle.

$ yarn run truffle migrate --compile-all --reset
$ colony service truffle migrate --compile-all --reset
error: unknown option `--compile-all'
error Command failed with exit code 1.

Can you allow all truffle options to be passed through to truffle?

Similarly, it would be great if we can pass additional ganache arguments as needed to ganache.

Another opportunity for enhancement is related to this comment in the contract migration:

// The address of the first colony created with `yarn colony-setup`
const colonyAddress = "0xEc46E0d7208FF021CDb5B9D47196adb8bbe07a3D";

Having to look up the address and insert it manually into the migration is something I have been doing as well, but it would be really helpful if this process could be automated. Perhaps on deployment of the colony contracts the address could be written to a config file e.g. colony-config.js in the root of the project, so that it could be opened and read by the migrations? That config file could store the address of the ColonyNetwork for each network to which it is deployed. (The mainnet, Rinkeby official deployments could also be hard coded there since users will not be deploying those themselves generally.)

Thanks for considering those. Let me know if I should submit issues on Github for them.

1 Like
#9

Awesome! Glad to hear.

For the truffle options, I just published an updated colony-cli package that allows truffle options.

The ganache options are a bit trickier because the current version of colonyNetwork uses specific accounts that are required in the deployment process but I think we could still make it work.

I like the idea of the config file that would be created/updated upon running colony-setup. I have a few more ideas to improve this service command as well, one being exploring the possibility of turning it into a prompt.

Opening issues in colonyStarter for the two recommendations above would be great. Thanks again!