Contributing to EmDash

EmDash is a pnpm monorepo. The main package is packages/core, published as emdash; it contains the Astro integration, REST API, database layer, schema management, and plugin system. The React admin UI lives in packages/admin.

This page gives you the quickest path to a working development environment. CONTRIBUTING.md is the canonical source for prerequisites, repository layout, contribution policy, required checks, changesets, and pull request requirements.

Local setup

1. Clone, install, and build the workspace.

   git clone https://github.com/emdash-cms/emdash.git
   cd emdash
   pnpm install
   pnpm build

2. Start the primary development demo.

   cd demos/simple
   pnpm dev

   The demo runs on Node.js with SQLite at http://localhost:4321. On the first request to an empty database, it also applies the sample content from seed/seed.json.

3. Open the admin panel.

   For the fastest local setup, open the development bypass. It runs migrations, creates a development administrator, signs you in, and redirects to the admin panel.

   To test the passkey setup flow instead, open the admin panel. The setup wizard creates the database, runs migrations, and prompts you to create an administrator account.

Development workflow

Watch mode

When you change packages/core while running the demo, use two terminals so the package rebuilds automatically:

# Terminal 1 — rebuild packages/core on change
cd packages/core && pnpm dev

# Terminal 2 — run the demo
cd demos/simple && pnpm dev

Checks

Run the required checks from the repository root before you commit:

pnpm typecheck    # TypeScript
pnpm lint         # full type-aware lint
pnpm format       # auto-format with oxfmt and Prettier

Caution

Type checking and linting must both pass. Don’t commit with known failures.

Tests

All tests

pnpm test

Core only

cd packages/core && pnpm test

Watch mode

cd packages/core && pnpm test --watch

E2E

pnpm test:e2e    # starts its own server

Tests use real in-memory SQLite databases instead of database mocks. Each test gets a fresh database.

Choose a contribution path

Bug fixes, documentation, and translations can go directly to a pull request. Bug fixes must include a failing test that reproduces the problem. Translation contributions follow the translation workflow.

Features and refactors require a maintainer-approved Discussion before implementation. Feature pull requests without that approval are closed. Read the full contribution policy before starting work so you know which path applies.

Documentation changes must also follow the documentation style guide.

For the main execution paths through EmDash, read Architecture (internals). Code-level patterns and invariants are documented in AGENTS.md.