Should capsule focus on just scaffolding?

[blckngm]

Related: #46 (remove test), #79 (remove deploy), #84 (build with cross)

If we use cross / cargo / Makefile to build contracts, cargo and ckb-testtool to test, ckb-cli to deploy, and ckb-debugger to debug, capsule can focus on just scaffolding.

[jjyr]

In my opinion, the problem with CKB tools is that they do not provide developers with a unified interface and configuration. This creates a high barrier for developers to learn these tools.

While removing redundancy from a maintenance perspective can be helpful, it alone will not reduce the developer's barrier. Instead, we should focus on solving the problems within the capsule framework. To do this, we should maintain a set of unified tools (which may be a thin wrapper over other tools). Developers can then choose these tools and learn how to use them without additional complex setup or learning.

The framework found at https://github.com/foundry-rs/foundry demonstrates good developer experience on Ethereum. We should strive to bring a similar experience to CKB.

[blckngm]

If the contracts and tests are written in rust, for building, testing, linting and even fuzzing (with cargo fuzz), cargo (and cross) already provides the unified interface and configuration. Removing capsule from the process doesn't just decrease our maintenance burden, it also lowers the cognitive overhead of contract developers, e.g. #26.

Deployment and debugging are more complicated. But there doesn't seem to be much that need to be unified between there different tasks, esp. deployment vs the rest. Testing and debugging are more related, here I think we should try to make it easier to debug transactions in ckb-testtool, e.g. we can add a function to invoke ckb-debugger for some tx, or add the option to automatically invoke ckb-debugger if verification fails, etc.