AGENTS.md · git:20261102.0ab2067 · 2026-11-02 · sha256 6d957e0485daea28

AGENTS.md git:20261102.0ab2067A

Immutable. This exact content never changes and is served at /api/v1/blob/6d957e0485daea28.

# melonJS — working in this repository

Instructions for coding agents (and people) working **on** melonJS: the
engine, its plugins and adapters, and the examples. For a game that *uses*
melonJS, copy `packages/melonjs/skills/AGENTS.md` into that game instead.

## Read the skills before writing engine-facing code

The engine ships task-oriented guides under
[`packages/melonjs/skills/`](packages/melonjs/skills/), one per subsystem, each
ending with a symptom → cause table. They are written for code that uses the
engine, which is exactly what an example, a plugin or a test is.

**Before writing an example, a plugin, a test or an engine feature, read the
router, [`packages/melonjs/skills/melonjs/SKILL.md`](packages/melonjs/skills/melonjs/SKILL.md),
then the one or two skills it points at.** Its "Prefer built-in features"
section lists what not to hand-roll: `ParticleEmitter` and `Trail`, `Tween`,
`TextureAtlas`, the `ShaderEffect` presets, the UI widgets, `BitmapText`,
`viewport.shake` / `fadeIn` / `fadeOut`, `save`, `state.pause()`, Tiled tile
layers read and changed with `cellAt` / `setTile`. An example that re-implements
one of them teaches the wrong thing.

For anything the skills do not cover, read the source under
`packages/melonjs/src/`, whose public API is documented with TSDoc, or the
generated index, <https://melonjs.github.io/melonJS/llms.txt>.

## Repository layout

A pnpm workspace (`packages/*`), built with Turborepo. Node 24 or later.

| Package | What it is |
| --- | --- |
| `packages/melonjs` | the engine: `src/`, browser tests in `tests/`, the skills in `skills/` |
| `packages/examples` | the examples site (Vite + React): one folder per example in `src/examples/`, registered in `src/main.tsx` |
| `packages/debug-plugin` | the debug panel |
| `packages/gamepad-plugin` | on-screen touch controls reported as a gamepad |
| `packages/spine-plugin` | Spine skeletal animation |
| `packages/tiled-inflate-plugin` | compressed Tiled maps |
| `packages/capacitor-plugin` | Capacitor lifecycle and hardware back button |
| `packages/matter-adapter`, `packages/planck-adapter` | physics engines that replace the built-in world |
| `packages/create-melonjs` | the project scaffolder |
| `packages/tsconfig` | shared TypeScript configuration |

## Commands

```bash
pnpm install
pnpm build                             # every package (Turborepo)
pnpm dev                               # engine in watch mode + the examples site
pnpm test                              # the engine's browser tests (Vitest + Playwright)
pnpm -F @melonjs/gamepad-plugin test   # one package's tests (those that have them)
pnpm lint                              # build, ESLint, Biome and the type checks
pnpm -F melonjs test:types             # the engine's type check alone
pnpm doc                               # the API docs, into packages/melonjs/docs/
```

Tests run in Chromium through Playwright: a renderer, a pointer and a canvas are
real, so test through them rather than mocking them.

## Conventions

- Tabs, strict equality, and the patterns of the code around the change; Biome
  and ESLint enforce the rest. See [`CONTRIBUTING.md`](CONTRIBUTING.md).
- **Changelogs.** Each package has its own `CHANGELOG.md`. A user-facing change
  goes under the `_unreleased_` heading of the package it changes, written as
  `CONTRIBUTING.md` describes. Examples, tests and internals stay out of it.
- **Public API.** Document it with TSDoc. A plugin's new public type also needs
  exporting from `packages/melonjs/scripts/docs/api-entry.ts`, or the API site
  leaves it out; `pnpm doc` shows the result.
- **Skills are part of the change.** A change to what an engine or plugin API
  does, or a new one, updates the skill that covers it in the same change:
  usage, pitfalls and symptom rows. Keep a skill's `description` within 1024
  characters.
- **Examples.** Build the example with `createExampleComponent` from
  `src/examples/utils.tsx`, put its assets in
  `packages/examples/public/assets/<example>/`, and credit any third-party asset,
  with its license, in `packages/examples/LICENSE.md`. An example shows how the
  engine is meant to be used, so it uses the engine's features rather than its
  own versions of them (see the skills above).

## Branches, pull requests and releases

- Work on a branch from `master`. Commit and push when asked, and only open a
  pull request, merge or publish when asked to. Pull requests follow
  `.github/pull_request_template.md`.
- A package is released by a small pull request that sets its `package.json`
  version and dates its changelog section, then the **Publish to npm** GitHub
  Action (`publish.yml`, run by hand with the package name, a dry run first).
  It publishes with npm provenance.