Estructura del Proyecto
Un workspace de Anchor separa los programas en cadena, las pruebas del cliente y la configuración de despliegue. Saber dónde vive cada artefacto evita la deriva del IDL y los scripts de despliegue rotos.
//
Busca en todas las páginas de la documentación
Un workspace de Anchor separa los programas en cadena, las pruebas del cliente y la configuración de despliegue. Saber dónde vive cada artefacto evita la deriva del IDL y los scripts de despliegue rotos.
my_workspace/
Anchor.toml # cluster, scripts, IDs de programa
Cargo.toml # raíz del workspace
programs/
my_program/
Cargo.toml # anchor-lang = "0.32.1"
src/lib.rs
tests/
my_program.ts
target/
deploy/ # .so después de la compilación
idl/ # IDL JSONCuándo usar esto: Estás incorporándote a un repositorio existente o dividiendo un programa en múltiples crates.
# Anchor.toml (extracto)
[toolchain]
anchor_version = "0.32.1"
[programs.localnet]
my_program = "Fg6PaFpoGXkYsidMpWTK6W2BeZ7FEfcYkg476zPFsLnS"
[scripts]
test = "yarn run ts-mocha -p ./tsconfig.json -t 1000000 tests/**/*.ts"# Cargo.toml (raíz del workspace)
[workspace]
members = ["programs/*"]
resolver = "2"Lo que esto demuestra:
Anchor.toml es la única fuente para los IDs de programa por cluster.programs/.target/idl/ se genera; no lo edites manualmente.programs/* con un lockfile compartido.lib.rs con #[program], structs de cuenta y tipos de estado.anchor build escribe el JSON utilizado por los clientes TS y declare_program!.[scripts] conecta las pruebas de Anchor con tu framework de pruebas TS.| Ruta | Propósito |
|---|---|
programs/*/src/lib.rs | Lógica en cadena |
Anchor.toml | Objetivos de despliegue y scripts de prueba |
target/idl/*.json | Entrada para la generación de código del cliente |
target/deploy/*.so | Binario de programa actualizable |
anchor build.lib.rs - El despliegue usa una clave diferente a declare_id!. Solución: Ejecutar anchor keys sync después del despliegue.anchor test no puede encontrarlas. Solución: Mantener las pruebas bajo tests/ según la convención de Anchor.members del Cargo.toml raíz.anchor-lang y anchor-spl en 0.32.1.| Alternativa | Usar Cuando | No Usar Cuando |
|---|---|---|
| Monorepo con múltiples workspaces de Anchor | Productos independientes que comparten infraestructura | Programa único con diseño simple |
Workspace nativo de Cargo sin Anchor.toml | Control máximo, sin IDL | Quieres clientes tipados y restricciones |
| Diseño Pinocchio/Steel | Programas críticos para la CU | Necesitas macros de cuenta de Anchor |
0.32.1 para anchor-lang, la CLI de Anchor y los ejemplos en esta sección.
Sí. Solana CLI 3.0.10 maneja los keypairs, airdrops y la inspección de solana program.
En target/idl/<program>.json en tu workspace.
Sí, pero cada campo no verificado necesita restricciones explícitas o comprobaciones del manejador.
Usa anchor test con Surfpool 0.12.0 o LiteSVM 0.6.x en CI.
El discriminador de cuenta de Anchor; no lo elimines al dimensionar space.
Sí, o publica el IDL en cadena para que los clientes tengan una fuente canónica.
Ejecuta con logs; Anchor imprime el nombre de la restricción y el índice de la cuenta.
Sí. Esta pila está dirigida a validadores Agave con Solana CLI 3.0.10.
Consulta los artículos hermanos en "Relacionados" para temas más profundos sobre la estructura del proyecto.
Versiones de la Pila: Esta página fue escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, anchor-lang 0.32.1, Rust 1.91.1, @solana/kit 7.0.0, Surfpool 0.12.0, y LiteSVM 0.6.x.
Revisado por Chris St. John·Última actualización: 19 jul 2026