|
| 1 | +# Charlie instructions for jsx-email (next/v3 branch) |
| 2 | + |
| 3 | +Repo‑specific rules that keep Charlie aligned with this codebase and review preferences. Keep diffs small, mirror existing patterns, and don’t widen scope beyond the request. |
| 4 | + |
| 5 | +## Scope |
| 6 | +Applies to the entire repository, with extra focus on `packages/jsx-email` and its tests. |
| 7 | + |
| 8 | +## Context |
| 9 | +- Monorepo using pnpm + Moon. Most tasks are run with `pnpm moon run <project>:<task>`. |
| 10 | +- Task inheritance lives in `.moon/tasks.yml`. Each project can add/override tasks in its own `moon.yml` (for example, `packages/jsx-email/moon.yml`). The root `moon.yml` defines repository tasks and is aliased as the `repo` project. |
| 11 | +- TypeScript uses ESM with NodeNext resolution; relative imports in source include the `.js` suffix. |
| 12 | +- Tests use Vitest; snapshots live in `.snapshots` next to tests (custom resolver). |
| 13 | +- GitHub Actions sets `FORCE_COLOR=1` when running tests; local runs must mirror this to avoid ANSI snapshot diffs. |
| 14 | +- Conventional Commits are the norm (e.g., `fix(jsx-email): …`). PRs should use the repository template. |
| 15 | +- Conventional Commit scopes map to affected project name(s) under `packages/` (e.g., `(jsx-email)`, `(plugin-inline)`, `(create-jsx-email)`). When multiple projects are affected, list each name in the scope, comma‑separated with no spaces (e.g., `(plugin-inline,plugin-pretty)`). PRs should use the repository template. |
| 16 | +- For the ongoing `next/v3` alignment work on `<Raw>` / `<Conditional>` behavior and core correctness (tracked in #348), branch from `origin/next/v3` and open pull requests with `base` set to `next/v3` (not `main`). Mention `#348` in the PR description for traceability. |
| 17 | + |
| 18 | +## Rules |
| 19 | +- [R1] Stay on task. Do not add refactors, helpers, or style tweaks outside the explicit ask. Keep diffs minimal. |
| 20 | +- [R2] Tests and snapshots: |
| 21 | + - Run with `FORCE_COLOR=1` to match CI. |
| 22 | + - Never change log/ANSI‑colored snapshots to “de‑colorize” or “stabilize” output. If a log snapshot fails, fix the cause or mirror CI settings; do not rewrite the assertion shape. |
| 23 | + - Do not introduce “snapshot normalization” helpers (e.g., projecting only parts of config objects) unless a maintainer requests it. |
| 24 | + - Place/update snapshots under `.snapshots` alongside the test file; prefer targeted assertions plus snapshots when behavior changes intentionally. |
| 25 | +- [R3] Writing tests for `packages/jsx-email`: |
| 26 | + - Prefer importing from package source (e.g., `../src/index.ts`) for new tests to avoid prebuild coupling. If an existing suite imports from `dist`, keep that pattern for that suite. |
| 27 | + - Avoid adding `// @ts-ignore` to suppress React imports; tests can rely on the React automatic JSX runtime. Don’t add new ignores. |
| 28 | + - Follow NodeNext import style in source files (relative imports include `.js`). |
| 29 | +- [R4] Verification commands (run locally before marking a PR Ready for changes that affect code, tests, or tooling config): |
| 30 | + - Build artifacts used by tests: |
| 31 | + - `pnpm moon run plugin-inline:build plugin-minify:build plugin-pretty:build` |
| 32 | + - `pnpm moon run jsx-email:build` |
| 33 | + - Lint: `pnpm moon run repo:lint` |
| 34 | + - Tests (jsx-email package, mirroring the `next/v3` CI setup): `pnpm moon run jsx-email:test` |
| 35 | + - TypeScript (package): `pnpm moon run jsx-email:tsc` |
| 36 | + - Do not change tool configs or CI to make checks pass. |
| 37 | + - For documentation-only or `.charlie`-only changes that do not affect CI, code, or tests, you may skip these commands, but prefer running at least `pnpm moon run repo:lint` when in doubt. |
| 38 | +- [R4.1] Linting (must run before pushing any commits): |
| 39 | + - Run repo linting via Moon: `pnpm moon run repo:lint`. |
| 40 | + - Do not push if linting reports errors anywhere. Fix them or coordinate a follow‑up if they are unrelated but surfaced by your changes. |
| 41 | + - If linting reports warnings in files you modified, resolve those warnings before pushing. |
| 42 | + - For quick checks while iterating, you may run ESLint scoped to touched files, but always run the full `repo:lint` before the final push. |
| 43 | +- [R5] Git & PRs: |
| 44 | + - Branch names (from humans): `{type}/{project}/{short-desc}` — for example, `fix/jsx-email/conditional-endif-slash`. Use the package with the most changes (or the intended target) for `{project}`, and let `{short-desc}` be a descriptive phrase or a short slug. |
| 45 | + - Conventional Commits scope = affected project name(s) from `packages/`. Examples: `fix(jsx-email): …`, `refactor(plugin-inline,plugin-pretty): …`. For multiple projects, list names comma-separated with no spaces. |
| 46 | + - Commit messages use Conventional Commits; ≤ 72 chars in the subject; no emojis. |
| 47 | + - PRs must use the repository template as-is — Charlie is not allowed to remove sections from the template. |
| 48 | + - Start as Draft when work is in flux; mark Ready only after local verification passes and the description reflects the actual changes. |
| 49 | + - Don’t add novel labels. Assign and request review from the human requester when appropriate. |
| 50 | + |
| 51 | +> Conditional/Raw specifics have been moved to a dedicated playbook. See `.charlie/playbooks/conditional-and-raw.md`. |
| 52 | +
|
| 53 | +## References |
| 54 | +1. CI workflow (test color): `.github/workflows/test-*.yml` (see `FORCE_COLOR=1` in test steps) |
| 55 | +2. Vitest shared config: `shared/vitest.config.ts` |
| 56 | +3. Moon tasks inheritance: `.moon/tasks.yml`; per-project tasks: `apps/*/moon.yml`, `packages/*/moon.yml`, `test/*/moon.yml`; repository tasks: `moon.yml` (project `repo`) |
| 57 | +4. jsx-email package tasks: `packages/jsx-email/moon.yml` |
| 58 | +5. Conventional Commits: https://www.conventionalcommits.org/en/v1.0.0/ |
| 59 | +6. Conditional/Raw playbook: `.charlie/playbooks/conditional-and-raw.md` |
0 commit comments