|
| 1 | +# Repository Guidance |
| 2 | + |
| 3 | +This file applies to the entire `deck.gl` repository. More specific `AGENTS.md` files in |
| 4 | +subdirectories may add local guidance. |
| 5 | + |
| 6 | +## Setup Commands |
| 7 | + |
| 8 | +- Install dependencies from the repo root: `yarn` |
| 9 | +- Build packages: `yarn build` |
| 10 | +- Run lint: `yarn lint` |
| 11 | +- Run all tests: `yarn test` |
| 12 | +- Run headless tests: `yarn test-headless` |
| 13 | +- Run render tests: `yarn test-render` |
| 14 | +- Run browser tests: `yarn test-browser` |
| 15 | +- Run website checks: `yarn test-website` |
| 16 | +- Use the exact script names from `package.json`; do not substitute spaced forms such as |
| 17 | + `yarn test headless`. |
| 18 | + |
| 19 | +## Before Committing |
| 20 | + |
| 21 | +- Run the most relevant tests for the changed packages, integrations, examples, or docs. |
| 22 | +- Run `yarn lint` for JavaScript and TypeScript changes. If lint failures are unrelated existing |
| 23 | + issues, call that out explicitly instead of hiding it. |
| 24 | +- If dependencies or package metadata changed, run `yarn` in the repo root and include any |
| 25 | + `yarn.lock` updates. |
| 26 | +- Do not reformat files you are not otherwise changing. Keep formatting-only churn separate from |
| 27 | + logic changes when practical. |
| 28 | + |
| 29 | +## Ready For Merge |
| 30 | + |
| 31 | +When asked to "get ready for merge", do a full merge-readiness pass: |
| 32 | + |
| 33 | +- Audit the public API surface touched by the change. Add or update TSDoc for every new or changed |
| 34 | + public class, function, method, property, and type. |
| 35 | +- Do a documentation pass when behavior, public API, examples, or migration guidance changed. |
| 36 | + Include relevant module docs, examples, sidebars, `docs/whats-new.md`, and upgrade or migration |
| 37 | + guide content. |
| 38 | +- Keep upgrade guides focused on breaking changes, removals, and deprecations. Put new-feature |
| 39 | + notes in the appropriate module docs or release notes instead. |
| 40 | +- Run `yarn` in the repo root so workspace metadata and `yarn.lock` are up to date, especially |
| 41 | + after any `package.json` change. |
| 42 | +- Run `yarn build` as the repo-wide type, declaration, and package build gate. |
| 43 | +- Run `yarn lint` for the final lint and formatting gate, then review the resulting diff. |
| 44 | +- Run the relevant tests for the changed packages, examples, integrations, and docs/website wiring. |
| 45 | + Typical commands are `yarn test`, `yarn test-headless`, `yarn test-render`, `yarn test-browser`, |
| 46 | + and `yarn test-website`. |
| 47 | +- For website or docs changes, run the website check from the repo root with `yarn test-website`. |
| 48 | +- Prepare a copyable Markdown PR description based on the branch diff compared to `master`. Start |
| 49 | + with the PR goals, then list the actual changes and validation. |
| 50 | +- In the final handoff, call out which merge-readiness gates passed, which were not run, and any |
| 51 | + remaining risk or unrelated pre-existing failures. |
| 52 | + |
| 53 | +## Code Style |
| 54 | + |
| 55 | +- Prefer TypeScript and ES module syntax. |
| 56 | +- Match the surrounding file style. In source files, use single quotes and semicolons. |
| 57 | +- Never abbreviate variable names. Use camelCase for variables, functions, and fields; PascalCase |
| 58 | + for types and classes; and CAPITAL_CASE for constants. |
| 59 | +- Prefer verb-noun names for functions and methods. |
| 60 | +- File names should be kebab-case unless an existing local convention differs. |
| 61 | + |
| 62 | +## Dependencies |
| 63 | + |
| 64 | +- Be conservative with new external dependencies. Add one only when it provides meaningful |
| 65 | + capability, not just a small utility. |
| 66 | +- Prefer vis.gl ecosystem packages when they fit the layering. Lower-level math or utility modules |
| 67 | + should not depend on deck.gl. |
| 68 | +- Prefer math.gl modules for math helpers. |
| 69 | +- Avoid lodash-style dependencies for simple operations. |
| 70 | + |
| 71 | +## Investigation |
| 72 | + |
| 73 | +- Do not fix problems by adding caches. Investigate why the problem occurs and address the root |
| 74 | + cause. |
0 commit comments