Contributing

Contribute to Logixlysia development

Thank you for your interest in contributing to Logixlysia! This guide will help you get started.

Getting Started

1. Fork the repository
2. Clone your fork:

   git clone https://github.com/PunGrumpy/logixlysia.git
   cd logixlysia

3. Install dependencies:

   bun install

Development

Logixlysia is built with:

• Bun as the runtime
• TypeScript for type safety
• ElysiaJS as the web framework

Project Structure

Logixlysia is a monorepo managed with Bun workspaces and Turbo:

apps/
├── docs/          # Documentation site (Blume)
└── elysia/        # Playground demo (Bun + TypeScript + Swagger)
packages/
├── logixlysia/    # The main Logixlysia package
├── bench/         # Benchmarks
└── typescript-config/

Inside packages/logixlysia/src/:

src/
├── config/        # Configuration resolution and presets
├── context/       # Request context handling
├── extensions/    # Additional features and extensions
├── helpers/       # Utility functions
├── logger/        # Core logging functionality
├── middleware/    # Elysia middleware/plugin hooks
├── output/        # Output handlers and formatters (console, file, rotation)
├── types/         # TypeScript types
├── utils/         # Shared utilities
├── websocket/     # WebSocket support
├── ai.ts          # AI-related helpers
├── errors.ts      # Structured error handling
├── index.ts       # Main entry point
├── interfaces.ts  # TypeScript interfaces
└── otel.ts        # OpenTelemetry integration

Running Tests

bun test

Watch mode:

bun test --watch

Code Style

• Follow TypeScript best practices
• Use meaningful variable and function names
• Add JSDoc comments for public APIs
• Keep functions small and focused

Changesets

We use Changesets to manage versions and changelogs. If your change affects the published logixlysia package, create a changeset before opening your pull request:

1. Run bun changeset in the repository root
2. Select the packages you’ve changed
3. Choose the appropriate version bump (patch, minor, or major)
4. Write a clear description of your changes — it will appear in the changelog
5. Commit the generated file in .changeset/ along with your changes

Docs-only or internal changes (no effect on the published package) don’t need a changeset.

Pull Request Process

1. Create a new branch for your feature/fix
2. Make your changes
3. Run tests and ensure they pass
4. Update documentation if needed
5. Submit a pull request with a clear description

PR Checklist

• Tests added/updated
• Documentation updated
• Code follows style guidelines
• Changes are backward compatible

Questions?

Feel free to open an issue if you have any questions or need help getting started.