There's most likely not gonna be any users once genesis is out, but it's good to start somewhere.

The docs can be as simple as some notes in the readme.

An API that vibranium can use to talk to blockchain clients. This will most likely be using rust-web3 for now.

As we're implementing crucial features as #78 it's important to have a solid test bed to ensure these features work.

Particularly for #78, there seem to be a lot of different cases used throughout some of the major DApps at Status and some of them are rather hard to rebuild in unit or e2e tests.

To increase the robustness of new features it'd be great if there was a way to run Vibranium against some of those major applications. Ideally, this would involved the whole development workflow from initialization/migration over compilation to deployment. To start small however, it'd be enough to maybe add a handful of projects as git submodules, have those checked out, add vibranium.toml config patches for every project, and run vibranium compile through all of them.

Later on we can think about introducing a fully automated migrate command and deployment in different environments etc.

Is your feature request related to a problem? Please describe.
The majority of DApp developers is used to using JSON when it comes to configuring things. Whether it's Embark or Truffle, both projects provide JSON config files. Vibranium on the other hand uses TOML. The primary reason for it to use TOML over JSON is that it was easier to get started.

However, since TOML is a subset of JSON, it shouldn't be hard to support JSON as well, and therefore, making it more natural/easier to use.

Describe the solution you'd like
Vibranium uses vibranium.toml to access project specific data. If we want to change the config file that vibranium should read from (e.g. vibranium.json) we'll have to provide another file that specifies the format (or provide a CLI flag).

It might make sense to default to JSON in the future, either way, the default needs to be overridable and persistent. We could introduce a .vibraniumrc file for this, which stores data like:

config_file_format = "json" // or "toml"

Vibranium can then look for such file and determine the config file format it's expecting onwards.

At the moment Vibranium uses rust-web3 v0.6.0. There seem to be some problems with that version, e.g. example of the project itself don't seem to properly work.

It might make sense to upgrade to some latest HEAD and check if it solves existing problems.

cli/tests/cli.rs is getting quite big. Probably makes sense to split it up into files per command init.rs, reset.rs, config.rs etc..

Here's a thread about this: https://twitter.com/slace/status/1135843467135836160

Describe the bug
When running

$ vibranium compile

and the sources to be compiled produce compiler warnings, vibranium will exit its process with an error state. This is because we're checking if std.err() is empty or not and if yes, we consider the program to have failed.

It turns out however, that it's a good practice to send program warnings to stderr, so we probably don't want to make it look like the program has failed.

Needs some way to figure out if we're indeed dealing with an error or not.

Should check for exit code of the underlying program

To Reproduce
Steps to reproduce the behavior:

1. Go to project with Solidity code that produce warnings on compilation
2. Run $ vibranium compile

Expected behavior
Warnings should not cause the process to exit with an error, or at least, it shouldn't look like that. E.g. right now, when there's an error being emitted, Vibranium clearly says that it has aborted due to [...].

In the case of compilation, the program has finished, just with warnings.

Additional context
Add any other context about the problem here.

Is your feature request related to a problem? Please describe.
Tools like Truffle and Embark support special syntaxes for imports inside of Solidity Smart Contracts. For example:

import 'openzeppelin/contracts/SomeContract'

Will actually import the Smart Contract from a library that lives inside node_modules, assuming that there's not file with the same path/name relative to the source file.

A lot of projects make use of this and similar syntax. Embark even fetches files if the import path is a remote path (something that can be done with Solidity's built-in module:path syntax as well).

This is a crucial feature to make vibranium usable for a lot of projects.

Describe the solution you'd like
This needs to be explored, but essentially, the idea would be to take the specified source files pass them through a transformation pipeline which will output the modified source somewhere inside the project's .vibranium folder and then have the compiler pick up the source files from there.

Current algo to merge default CLI options with custom ones is primitive and flaky. E.g. it relies on sorting which doesn't work well for this use case in the first place.

We can't always rely on a hard coded default, so it's better to get a gas price from the blockchain connector.

We need this because we'll have to ensure that, when using any of the supported blockchain clients, they are started with decent defaults, such as dev mode etc.

Vibranium should be able to keep track of what has been deployed so that future deployments can be made faster. Also, this is actually needed in order to implement #37 as we need a way to store the information of deployed contracts.

Tracking should be turned on by default and can be disabled using the following configuration:

[deployment]
  tracking_enabled = false

While implementing the strategies for different compilers was a great learning task, it might actually not be needed because, no matter what compiler program is used, we always spin up a child process with that program + its options.

The blockchain module implements a simplified strategy and should be considered for compiler as well.

While still functional, Error::description is a deprecated API which is why some libraries in the rust ecosystem are no longer implementing it.

This came up in the process of doing #35 and a discussion in tomusdrw/rust-web3#216.

The suggestion to use Display instead makes sense, however, so far we've used description() as a single source of truth, so we'll have to move them over.

With ethereum/solc-js#367 (comment) landed in solc-js, we can now safely roll back to using it on CI (and windows platforms).

We could leave the platform specific solc installations as they are right now, however, simply installing JS bindings through npm is more straight forward and streamlines the CI process across all platforms.

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: [e.g. iOS]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Smartphone (please complete the following information):

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 22]

Additional context
Add any other context about the problem here.

It would be great to put Genesis out on the cargo registry, but in a way that people can use vibranium CLI using

$ vibranium

as opposed to

$ vibranium-cli

Now that we have a simple and straight forward compile command in place, the next logical step would be to implement a simple deploy command.

Running

$ vibranium deploy

within a Vibranium project should look for already compiled Smart Contract artifacts and deploy them to a local chain.

This is useful when for example Vibranium's default ProjectConfig has changed.

If a vibranium.toml file isn't valid as ProjectConfig (e.g. missing fields), it won't do the reset because it tries to honor changes to existing properties.

Having a force option will tell Vibranium to just create a new vibranium.toml with defaults, discarding the existing config.

Is your feature request related to a problem? Please describe.
Deployments are tracked in an internal tracking.toml file. When working collaboratively on projects (and different environments), tracking data should be shared so developers of the project don't re-deploy they Smart Contracts individually.

Describe the solution you'd like
It should be possible to specify a source file in which the tracking data is written to. This enables users to put it under version control and therefore share it across a team.

Right now tracking can be enabled/disabled using:

[deployment]
  tracking_enabled: false # defaults to true

We should keep this option to not break existing projects. In addition we can make tracking and object and give it a enabled and source property:

[deployment]
  [deployment.tracking]
    enabled: false # defaults to true
    source: "tracking.toml"

This would make Vibranium put tracking.toml into the root of the project. It should be possible to make it a full path too.

In order to the an MVP out the door, the implementation of BlockchainConnector has been simplified by implementing rust-web3's exact interface.

Need to figure out how to make this truly generic so rust-web3 can indeed be swapped out if needed in the future.

Is your feature request related to a problem? Please describe.
DApps often rely on Smart Contracts that they don't and are already deployed on mainnet (or any other net for that matter). If a Smart Contract depends on such an already deployed one, one can add the address to the constructor parameters like this:

[[deployment.smart_contracts]]
  name = "SomeContract"
  args = [
    { value = "0x123...789", kind = "address" },
  ]

For better semantics, it'd be useful to have the already deployed Smart Contract added to the overall configuration as well (to give it a name) including its address and then referencing it using the directive syntax introduced in #57:

[[deployment.smart_contracts]]
  name = "ENSRegistry"
  address = "0x123...789"

[[deployment.smart_contracts]]
  name = "SomeContract"
  args = [
    { value = "$ENSRegistry", kind = "address" },
  ]

The directive would work as expected and `ENSRegistry would not be deployed as it already has an address.

This setup is particularly useful when deploying in different environment (which isn't supported yet), e.g. development env needs an ENSRegistry as well, however, that environment needs to deploy it first, whereas in product, we'd rely on the already deployed one.

At the moment, when running compile and the underlying compiler program fails, Vibranium should consider the entire command to fail.

Which code could need some refactor love?
A clear and concise description of which part of the codebase could need a refactor and why.

Describe the solution you'd like
A clear and concise description of what the refactor could look like.

Describe alternatives you've considered
A clear and concise description of any alternative solutions you've considered.

So far init can be used either inside an existing project or by providing a path to a project:

$ vibranium init # initializes vibranium project in current directory
$ vibranium init --path path/to/dir # initializes in given directory

This works great if one wants to use vibranium as part of a DApp where a front-end already exists. For Smart Contract only DApps, it'd be good if init would take care of scaffolding a project as well:

$ vibranium init path/that/doesnt/exist/yet

Describe the bug
Not really a bug, but should be changed/improved. Right now the supported protocol value in the blockchain connector configuration are rpc and ws.

When rpc is specified, Vibranium creates a blockchain connector using http protocol. It should be called like that in the config as well. So instead of doing:

[blockchain.connector]
  protocol = "rpc"
  host = "localhost"
  port = "8545"

It should be

[blockchain.connector]
  protocol = "http"
  host = "localhost"
  port = "8545"

Supported protocols are http and ws. Both make rpc calls. This should be added without breaking existing projects (using rpc should still work).

Which code could need some refactor love?

Vibranium comes with a battery of e2e tests which try to simulate the user experience full-circle. Some of the tests require compiled artifacts of Smart Contracts (e.g. deployment tests). That's why there are a lot of tests with preparations of test Smart Contracts and the compilation of such. Also, most of those tests rely on the same Smart Contract for testing.

There's a couple of things we can improve here, one of them being reduction of computation by providing the compilation artifacts of the test Smart Contract in question. The compiled artifact will be the same so there's no need to actually recompile it every time unless we aim to test anything specific to the compilation process itself.

Describe the solution you'd like

There's probably different ways to go about this, but the most straight forward would be to compile the test Smart Contract, take the bytecode and put it in a file somewhere inside the test folder. We can then introduce a helper function (e.g. create_test_artifacts(name: String)) that can be used to hydrate a freshly initialized vibranium project with artifacts.

Is your feature request related to a problem? Please describe.
There are cases where it's desired to have/deploy multiple Smart Contracts that come with the exact same functionality, but they are simply working with different data. E.g. think of a Smart Contract that implements collectibles, but it doesn't actually specify what those collectibles are (cats? dogs?). Assuming we want two Smart Contracts that implement collectibles, but different kind of collectibles, it's required to have a way to specify the "recipe" Smart Contract.

Describe the solution you'd like
It should be as simple as specifying what Smart Contract is used as a recipe for deploying another one:

[deployment]
  [[deployment.contracts]]
    name = "CatCollectible"
    instance_of = "Collectible"
    args = [
      { value = "cats", kind = "string" }
    ]

Notice it's not even needed to specifying Collectible in the deployment section if there isn't any additional configuration needed. Only thing that is needed is that Collectible has been compiled before deployment happens. Vibranium will find the ABI + Bytecode based on heuristics.

Describe alternatives you've considered
As far as I can see, the only thing that might be considered is the name of the property that defines the recipe Smart Contract. Instead of instance_of something like recipe or template could be used. However, there could be cases where Collectible should indeed be deployed as well, in which case it's not really a template. instance_of seems most natural and is used by the Embark project as well.

This is needed to make #36 more flexible

This is useful for testing as well. Something like:

$ vibranium config compiler.cmd vyper
$ vibranium config compiler.options "--foo" "--bar"
$ vibranium config --get compiler.cmd

Once #36 is done, it would be useful to have a command that outputs the deployed Smart Contracts and their addresses (similar to firebase-tools list) command.

Users should be able to define Smart Contracts as construction parameters of other Smart Contracts during deployment. Embark does this using a declarative directive syntax a la $ContractName.

We can probably use the same:

[deployment]
  [[deployment.smart_contracts]]
    name = "SimpleStorage"
    args = [
      { value: "$OtherContract", kind: "address" }
    ]

  [[deployment.smart_contracts]]
    name = "OtherContract"

Obviously, this means we need to determine a dependency tree first and ensure a dependency contract has been deployed before the one that uses it.

During argument tokenization we can figure out based on the kind: "address" and $ prefix that we're dealing with a directive.

Any compiler specific options can be applied to vibranium's compile command using the -- syntax. E.g:

$ vibranium compile --compiler solcjs -- --abi ...

This is great, however at the moment, some compiler options (defaults) are hard coded into the compiler strategies and cause issues when also applied using the above syntax.

E.g. solc doesn't errors out when the same options is applied more than once.

Vibranium should be smarter about this and determine/merge default options with the ones applied by the users before sending them to the command.

Once #30 is implemented we can use it to create a simple accounts command which outputs the dev accounts from the running blockchain client.

This crate seems to do a lot of things that is currently implemented custom in Vibranium. It could be beneficial to use it instead.