Project structure and design decisions
Architecture Overview
Understanding Astrolock’s design and structure.
Dual System Architecture
Astrolock consists of two main systems:
- Bashly CLI
- Astro Site
User-facing command-line interface built with Bashly.
- Purpose: Content management, site configuration, deployment
- Technology: Bash scripts
- Entry point:
bin/astrolock - Definition:
cli/bashly.yml
Static site generator built with Astro.
- Purpose: Generate HTML/CSS/JS from content
- Technology: TypeScript, Astro components
- Entry point:
src/pages/ - Configuration:
src/config/
User-facing command-line interface built with Bashly.
- Purpose: Content management, site configuration, deployment
- Technology: Bash scripts
- Entry point:
bin/astrolock - Definition:
cli/bashly.yml
Static site generator built with Astro.
- Purpose: Generate HTML/CSS/JS from content
- Technology: TypeScript, Astro components
- Entry point:
src/pages/ - Configuration:
src/config/
Key Directories
See Directory Structure for detailed file organization.
Configuration Flow
- User site has
config/*.jsonfiles - Environment variables (
ASTROLOCK_CONFIG_DIR) point to user config - Build process uses
src/lib/config/getSiteConfig.tsto load config - Astro components use dynamic config loaders
make build
└── yarn build
└── astro build
└── Reads config via getSiteConfig()
└── Processes content collections
└── Generates dist/Content Collections
Astro content collections defined in src/content.config.ts:
- blog - Blog posts
- authors - Author profiles
- pages - Static pages
- user-guide - Documentation
- [dynamic] - User-defined media collections
Environment Variables
| Variable | Purpose |
|---|---|
ASTROLOCK_CONFIG_DIR | User’s config directory |
ASTROLOCK_PUBLIC_DIR | User’s public assets directory |
ASTROLOCK_CONTENT_DIR | User’s content directory |
Design Principles
Info
Astrolock follows these core principles across all components.
- Separation of concerns - CLI handles user interaction, Astro handles generation
- Convention over configuration - Sensible defaults everywhere
- Environment-based configuration - Same codebase for all sites
- Static output - No runtime dependencies