Developer's Guide¶
This guide is for contributors and library maintainers of gaslamp.
Setup¶
Get your local environment ready for development.
- Dependencies — Required tools and packages
- Setup — Install and configure the development environment
- Install — Clone the repository and start a development branch
Workflow¶
Step-by-step guide for the build, test, and release cycle.
- Workflow Overview — Daily development and release commands
- Build — Type-check TypeScript
- Bundle — Bundle source for GAS
- Push — Push to Google Apps Script via clasp
- Testing — Run tests locally
- Formatter — Format source code
- Linter — Lint source code
- Docs — Build and preview documentation
- Release — Release a new version
Guidelines¶
Conventions and patterns used across the codebase.
- Naming Guidelines — Variable, function, and class naming conventions
- Style Guides — Code formatting and syntax preferences
- Docstring Standards — TypeDoc documentation format and best practices
- Design Patterns — Recurring architectural patterns and API consistency
- AI-Assisted Development — Prompts for Claude Code
Conceptual Guides¶
Philosophy and concepts behind gaslamp's design. Understand why things are built this way.
- Conceptual Guides Overview — Design philosophy and core principles
- Cell and Primitive Types — Why we separate raw GAS data from normalized data
- Data Orientation and Conversion — Why we support multiple data shapes
- Expressions and Predicates — Why filters are built, not evaluated on the fly
- FlameFrame and Validation — Why validation is a gate, not a transformer
- LazyFrame and Deferred Evaluation — Why we defer evaluation to apply optimizations
- FlameWright and Runtime Type Safety — Why type guards are essential in GAS
- BareFrame-First Design — Why transformation and validation are separate concerns
- ForgeFrame and Statistical Analysis — Why histograms are a specialized DataFrame operation
Contributing¶
How to contribute to the project.