A little more than a month after the formation of the aragonSDK Working Group, we’re proud to announce the release aragonCLI v7. But before we dive into the details of the release, let’s quickly discuss the context of why we formed this working group, and who we are.

A bit of context

Everyone in the Aragon community can appreciate how powerful the product we’re building is because once a few things start clicking in your mind, you come to understand the possibilities of what you can build with Aragon are endless. That’s why we do not only see a product that quickly improves and an increasingly engaged community, but we are also seeing a lot of developers creating new applications for the platform. The aragonSDK provides great tools for developing these applications, but we are well aware that there’s room for improvement of these tools.



The single purpose of the SDK working group, currently formed by A1, Autark, Mesh, and the wider Aragon community, is to take our user and developer experience to the next level. This does not only include improving our existing tools like the aragonCLI, but creating new tools, rearranging parts of the stack so that they are simpler to digest, and making significant improvements to our documentation. As a working group, we want to make developing and using all Aragon products and tools a delightful experience.

Version 7 release

So, what’s new with v7? The latest release of the CLI does not offer new features but has been completely refactored under the hood. Refactoring is usually not very exciting, but trust me, this time it is! This refactor eliminates a lot of technical debt and paves the way for what we’re calling “v8”, for the time being. Version 8 will not only feature a new version of the CLI but will introduce completely new elements to the aragonSDK. More about that later. Let’s go into the details of v7 first.

The new toolkit package

The most significant change in v7 is that we extracted all the logic from the CLI commands into an isolated @aragon/toolkit package that’s 100% agnostic of the user interface (e.g. yargs). Meaning, as of this release, the CLI created with yargs is merely one possible front-end, and you can start using the toolkit directly from your own Javascript projects 🎉



You can import the toolkit to your code, and do all sorts of things like creating new DAOs, acting via the Agent app of a DAO, and much more. Things that you could only do with the CLI, or with hard to produce custom code. For example, here’s a little script that uses the toolkit, which allows you to encode the installation and configuration of multiple apps into a single vote of a DAO.



In this example JS script, you can see how it uses the toolkit to create a DAO from the membership template, encode ten votes into an EVM script, and finally execute that script. All within Javascript! This effectively creates a single vote in the DAO with the ten votes bundled up in it. If you run the script and then run aragon start in your terminal, you should see the Aragon client open up in your browser. Go to the URL displayed by the script, and you’ll be able to see this bundled vote. If you execute it, you should see the ten votes spawn into existence. Cool right?



Feel free to experiment with the toolkit, but keep in mind this is an extremely early version of it. Even though the code is strong, its interface is unstable and subject to major changes in the near future. We are investing a great deal of effort (and <3) to make it as easy to use and consistent as possible. For now, we’ve simply extracted it into its own package. Next, we intend to shape and design its interface.



We hope this toolkit becomes a powerful tool for the Aragon developer community and that contributions flow as a single joint effort making it more useful and more useful with every iteration.

Multiple front-ends

With the logic extracted out of the @aragon/cli package , it is now merely a front-end. This will enable us to separate concerns and focus on improving the developer experience of this front-end. Most importantly, however, this allows us to start designing other front-ends. For example, we can begin exploring things like Remix plugins, or a CLI embedded in the Client, and more.

Tests, tests and more tests

Before v7, our test coverage in the CLI was a bit confusing and rather lacking in coverage with only 22 tests, most of which were mocked unit tests. With this release, we’ve made a huge effort to structure tests in a way that is very easy to understand and written more than 125 integration tests. We’re still far away from the golden 100% coverage goal, but 70% is a notable improvement from previous releases. Most importantly, we now have a clear path for getting to 100%. And we are getting there.



Visit our release page for more info on the changes and start using aragonCLI v7.

Version 8+

Even though the changes we’ve discussed in v7 are quite exciting by themselves, they are just reinforcing our foundations, so that we can support what’s coming in v8. We have so many new features and changes coming in 2020 that will completely transform the experience of using and developing on Aragon.



The Power CLI

While we were coding v7, we also performed a study of how people are currently using the CLI, as well as other parts of the Aragon stack. The first thing we noticed and verified, is that there are two very different types of users of the CLI: Power Users and Developers.



Developers use commands like start , run , ipfs start , etc, while Power Users just want to interact with DAOs (or architect DAOs for experimentation) with commands like dao new , dao exec , apm packages , etc. And both want to do these things as quickly and seamlessly as possible. There’s no reason for these two families of commands to coexist in the same tool. Having everything in the same tool makes it bloated, slow, and difficult to understand. The CLI currently supports more than 35 commands, including sub-commands nested at three different levels, all with cryptic options and aliases. Separating the Power User CLI and developer-focused tooling makes more sense than ever.



Our plans for the near future include moving all development-oriented commands like start , run , etc, out of the CLI, into create-aragon-app boxes that provide functionalities via plugins compatible with familiar workflows like Buidler. This will significantly reduce the complexity and installation times of the Power CLI, while making the developer experience much more flexible and modular, allowing us to support much-awaited features like full hot reloading.



On the other hand, the commands that remain in the CLI will all be more straightforward and faster for interacting with DAOs, the APM, etc. However, the problem still remains of having to remember a lot of commands, and most tediously, all of their parameters and options. To solve this problem, we plan to overhaul the CLI’s interface completely. While it will retain its current programmatic interface for usage in scripts, it will also expose an interactive experience that allows you to visualize available commands and their options as you type them, with inlined help and smart autocompletion. The new CLI will understand the context of the DAO you are working on and automatically populate known addresses, ABIs, and much, much more. This is why we’re calling it the “Power” CLI.



Maintenance

Of course, while we work on the Power CLI and development plugins, we also must continue the foundational work started in v7. The toolkit API needs significant reshaping and expansion.We need to dramatically increase the test coverage of this toolkit, as well as the coverage of other packages like the CLI and create-aragon-app packages. This maintenance work will happen in parallel with the development of new features.



Other parts of the stack

We understand that improving the developer experience does not only mean improving and producing tools. The best possible improvement we could ever make is to have a stack that is easier to understand, where the moving parts are coherent in isolation of each other. We want everyone to be able to quickly jump in and develop on Aragon, not only seasoned veterans. Newcomers should arrive to the documentation and be able to understand the concept of “A”, without having to detour to “X”, “Y” and “Z” before coming back to “A” only to find that they’ve forgotten what they were trying to do in the first place. These initiatives are not in our immediate roadmap, but we will address them as soon as possible.



Community effort

We hope that you like all these changes that we’re working on. We want to unify the developer experience for all Aradevs and provide an SDK that we can all build together and improve collaboratively. An experience that is easy to understand and to contribute to, and one that, in the long term, makes people conceive the Aragon stack as a simple and straightforward thing.



Please let us know what you think about our roadmap! We are completely open to discussing this with anyone willing and make course corrections as we move forward.