Skip to main content
Thank you for your interest in contributing to Yasumu! We welcome contributions from the community and appreciate your help in making Yasumu better.

​
Don’t know where to start?

If you don’t know where to start, check the issue tracker on GitHub. Look for issues labeled with good first issue or help wanted to find beginner-friendly tasks.

​
Architecture overview

Yasumu is designed around a modular architecture where core features are implemented as independent packages. Understanding this architecture will help you navigate the codebase and contribute effectively.

​
Package structure

  • @yasumu/common: A shared package that exposes common types and utilities used across the ecosystem.
  • @yasumu/core: The client SDK that defines how Yasumu’s data is managed and structured.
  • @yasumu/rpc: Defines external operations and exposes the PlatformBridge interface, allowing @yasumu/core to communicate with the underlying platform (file system, external servers, etc.).
  • @yasumu/tanxium: The backend API running on Yasumu’s custom JS/TS runtime. It uses a Hono server and @yasumu/den (a custom NestJS-like dependency injection container and module system) to expose RPC-friendly endpoints. It manages CRUD operations using Drizzle ORM and a local SQLite database powered by node:sqlite, which is then synchronized with the file system.
  • @yasumu/schema: Handles the serialization and deserialization of Yasumu’s entities into the plain text .ysl (Yasumu Schema Language) format.
Core features are implemented as independent modules, making it possible to:
  • Add new protocol support without touching the core system
  • Extend the application with plugins
  • Run specific components in different environments
  • Integrate Yasumu into custom developer tooling
This architecture keeps the system maintainable while allowing it to grow organically with new use cases.

​
Before you contribute

​
Check for existing PRs

Before making a pull request, check if someone else has already made a PR for that specific topic. Avoid duplicated PRs by searching through open pull requests.

​
Commit conventions

Follow conventional commits format while committing. The commit message should be structured as follows: 
<type>[optional scope]: <description>

[optional body]

[optional footer]

​
Commit types

  • fix: patches a bug in your codebase (correlates with PATCH in semantic versioning)
  • feat: introduces a new feature to the codebase (correlates with MINOR in semantic versioning)
  • BREAKING CHANGE: introduces a breaking API change (correlates with MAJOR in semantic versioning)
  • Others: chore:, docs:, style:, refactor:, perf:, test:

​
Examples

Commit message with description: 
docs: correct spelling of CHANGELOG
Commit message with scope: 
feat(lang): add polish language
Commit message with breaking change: 
feat: allow provided config object to extend other configs

BREAKING CHANGE: `extends` key in config file is now used for extending other config files
Commit message for a fix: 
fix: correct minor typos in code

see the issue for details on the typos fixed

closes issue #12

​
File naming conventions

Prefer the use of kebab-case for file naming. Files such as services may append .service to the name (for example: user.service.ts). Why kebab-case?
  • Readability: Words are clearly separated with hyphens, making file names easier to read at a glance.
  • Consistency: Uniform naming avoids confusion when importing files, especially in case-sensitive file systems.
  • URL & CLI friendly: Works seamlessly in URLs and command-line operations without needing quotes or escaping spaces.
  • Cross-platform safe: Reduces issues with file systems that treat uppercase/lowercase differently.
Using kebab-case consistently helps maintain a clean, professional, and easily navigable project structure.

​
Quality checks

Make sure to properly format the source code, check for linter errors, and test the code before pushing.
Run pnpm format to format your code and pnpm build to ensure everything compiles correctly.

​
Getting help

If you have questions or need help with your contribution:
  • Open a discussion on GitHub
  • Join our community channels (if available)
  • Comment on the relevant issue or PR
Happy coding!

Build docs developers (and LLMs) love

Get started for freeTalk to us