Problem: Testing in local is difficult due to not having all the programs of mainnet-beta
A lot of people give up on testing in local because all of their programs required in prod don’t exist. There is a way to load each program in a local environment, but it is cumbersome and causes everyone to reinvent the wheel when loading a specific program set that is commonly used such as Metaplex for NFTs.
Not only that, but a decent amount of programs such as Openbook require web2 infra to work correctly. Without good documentation, developers cannot correctly test these programs locally.
Solution: Helm-like plugin framework for loading programs
If someone could download plugins to load programs and run them locally, local testing would be much easier.
On startup, we run solana-test-validator. To load individual programs, we add the --bpf-program 9xQeWvG816bUx9EPjHmaT23yvVM2ZWbrrpZb9PusVFin binary.so with any programs we’d like to load. Anchor allows you to do this a little bit easier by listing the programs in the cargo.toml file.
This brings us closer to the solution, but not good enough for local development to be a breeze since everyone is redoing this for their individual programs.
Let’s bring it into a folder structure.
Under a specified plugin folder, you can add each individual plugin with the required configurations to run. A config.yml can list all the required mainnet-beta programs and accounts to load locally to run. The Dockerfile can be used to run any web2 infra required to get the program to work. Any program developer can provide this structure so that it is copy-pastable to anyone working in local.
Proposed config.yml structure:
programs:
-
programId1 or programName(as referenced in explorer)
-
programId2
accounts:
-
account1
-
account2
overrides:
-
accountAddress: address
accountOwner: address
The Dockerfile can just be loaded via a docker network across all plugins so that the local-test-validator can run with each web2 infra running separately.
Option 1: Add —plugin-dir to local-test-validator
We can add a new flag called --plugin-dir to the local-test-validator.
Pros:
- All-in-one tool for local testing
- Works with Anchor by default
Cons:
- Bloats the local-test-validator more
- Not aligned with Labs toolset
- Outside maintainers may cause some friction
Option 2: Completely new CLI using local-test-validator
We could start a whole new CLI that uses local-test-validator under the hood, much like Anchor-CLI.
Pros:
- Fully maintained by new team
- Freedom to manage and update outside of local-test-validator
- Can add new features
Cons:
- Yet another CLI
Option 3: Add to Anchor CLI
Pros:
- Immediately available to all users of Anchor
Cons:
- Tied directly to Anchor
Recommendation
Let’s try for option 2 and build it out so that it can extend more than just the plugin framework. This CLI can work under the hood with something like Lava Suite to give even better capabilities.
Work required
- Account overrides needs to be added and exposed on the local-test-validator
- Based on the option chosen, create CLI or add new CLI command to load plugins
- Setup plugin repository for anyone to add new plugins to
- Create a few example plugins(Metaplex, Openbook) for usage
