aragon / aragon-cli Goto Github PK

Replace module with app everywhere

Multi-line declarations like

    function _makePaymentTransaction(
        ERC20 _token,
        address _receiver,
        uint256 _amount,
        uint256 _paymentId
        ) internal
    {
        ...
    }

Are treated as public by the regex.

Unfortunately the antr4 grammar doesn't support natspec yet, but maybe we should be looking at something more robust for this...

Steps to reproduce:

aragon init test.aragonpm.eth bare
cd test
aragon run
aragon version minor
aragon run

Other package already uses sha3 instead of js-sha3, so we should remove the latter as a dependency

• Should allow you to add a simple name and introduce the APM suffix aragon init matos -> aragon init matos.aragonpm.eth react
• Should really exit the process if there is an error and not keep going

Right now there's an --rpc flag to set the Web3 provider, but the name is not good and it should be renamed. We should also have a flag and a config option to set the URL of the IPFS node.

We have an issue right now where packages are named e.g. foo.aragonpm.test, but this makes it cumbersome to publish the package to the live APM repositories (e.g. foo.aragonpm.eth).

We should think about how we want to do this. One idea would be to only have foo.aragonpm, as it denotes the package name and the repository, but the TLD would be computed from the chain ID.

For example, for mainnet the computed package name from foo.aragonpm would be foo.aragonpm.eth. Likewise, for something like foo.0xpackages on the mainnet, it would compute to foo.0xpackages.eth.

As @Smokyish pointed out for consistency with other project names would be a good idea to rename.

Also this tool has been expanding a little bit in scope to the point it is not only useful to develop and publish Aragon apps, but to inspect and interact with DAOs from a CLI.

We will proceed with the rename in 36h if no objections are raised here.

Bump version in package.json after these two are solved:

• aragon/aragon-apps#315
• aragon/aragen#2

All APM-specific functions should be moved to its own file(s). For inspiration, see: https://github.com/aragon/node-aragon/blob/master/src/apm/index.js

Instead of working in a custom deploy flow for our own development environment for Aragon apps, we should generalize this at the aragon-dev-cli level to setup a complete environment.

$ aragon-dev-cli setup [--registry-name Domain name for registry (default: aragonpm.test)]

Steps needed:

• Deploy an ENS instance a create the needed subnodes until registryName is owned by the sender.
• Deploy an APM instance with the rootnode for registryName. Call apm.setResolver().

This migration file for APM where all this steps are performed can be used for reference.

We need a way to save both the ENS and the registry name so that following aragon-dev-cli executions automatically use them (maybe add them to a config file that gets read if no flags are provided?).

Because of our use of Proxies, child contracts won't initialize global variables when created. In case an app being published does this, we should at least warn the developer.

contract MyFancyApp is App {
  uint initialState = 1;
}

In the above example, when used behind a proxy, initialState will be 0, even though the expectation reading the code is that it will be 1.

We should encourage the developer to make it something like:

contract MyFancyApp is App {
  uint initialState;

  function initialize() onlyInit { initialState = 1; }
}

Edit: this should apply to logic in constructors too

Now that both APM registries and repos are full Aragon apps, we need node-aragon to calculate different fwd paths for creating repos and new versions in them.

@sohkai proposed this rename and I think it is amazing

In case we ever make a CLI client, that could be called dao

aragon publish template.aragonpm.eth
dao new-org template.aragonpm.eth

1. Clone dapp at a specific tag to a temporary folder (if not done already)
2. Run the dapp with the correct settings

It should be possible to specify a template when running aragon-dev-cli init to scaffold a new module.

To make the developer experience a bit less painful we'll add a playground command that will run a local module in an instance of the Aragon Desktop Dapp.

aragon/aragon-apps#79

Ideally you would have one keyfile for all networks, so a format like this could be cool:

{
  [networkId]: string
}

ENS config etc. should be kept in a separate configuration file that you can share among team members (or maybe even commit to GitHub) in a similar format.

Run linting, tests and generate coverage reports.

Nested node_modules: [this line] should contain something like **/node_modules instead (should probably be tested, not 100% of the globstar).

It'd also be real nice if it was the same as .gitignore or .npmignore.

The code is a bit messy, so we'll need to do some initial cleaning.

• #1: Move handlers into own files
• #2: Create multiple reporters
• #3: Abstract APM storage providers

Right now the workflow is one of:

• truffle build
• truffle deploy
• aragon-dev-cli publish
• Sign and broadcast transaction

It would be cool if we could do something like

• truffle deploy

which would build the application, deploy the contracts, generate the artifacts and publish the application to IPFS.

When running any commands with no rpc node is provided as a flag and there is no HTTP server listening at port 8545, I think it would be a good idea to start a testrpc node in the background with a huge amount of ETH for a dummy private key 0x1111....

Using this with #17 would allow for easy development with almost no setup.

Should just be marked as an invalid version

Things like address constant public ETH = address(0) are not included.

From discussions with @izqui we should maybe add a test command that works with either ava or mocha, or both, instead of relying on people to install Truffle.

Right now aragon-dev-cli ignores node_modules and .git, but this should be configurable.

If we can't connect to the IPFS node, we should tell the user. Same for Ethereum node, etc.

Because of the way upgradeability works, changing the storage layout would break apps.

It is possible to analyse what the contract storage would look like for a contract, and perhaps make a diff between two versions of the same app - e.g. the storage layout for v1.0.0 of the contract and v2.0.0.

If they differ in a breaking way (i.e. a type is changed in a specific storage slot), then we should emit an error in the CLI. This error should be skippable by explicitly adding a flag to the publish command.

We could extract this to a separate module and make it mandatory to publish your contract source for source code verification. This would also allow us to display errors to the user in case the storage layout would change between versions.

Relevant link on the storage layout of Solidity contracts: https://solidity.readthedocs.io/en/v0.4.21/miscellaneous.html#layout-of-state-variables-in-storage

Sort of related to #26 as they both do contract analysis

Makes the publisher feel 100% more relieved!

It is possible to specify per-project configuration in package.json, which makes it possible to avoid using flags when running commands, but this is currently undocumented.

Example

// In `package.json`
{
  config: {
    aragon: {
      modulePath: './path/to/frontend',
      contractArtifactsPath: './path/to/truffle/artifacts'
    }
  }
}

Some errors are ugly, some are unhandled. For a good developer experience, we want to catch 'em all.

From discussions with @izqui we should maybe add a compile command that compiles contracts instead of relying on Truffle.