- In Markdown files in the DOMStack repository, write prose with one sentence per source line so git diffs stay focused and readable.
- In GitHub pull request descriptions, issues, comments, and review replies, write each prose paragraph on a single source line, with blank lines between paragraphs, because GitHub renders individual newlines as line breaks.
- Preserve the line breaks required by Markdown lists, code blocks, tables, and other structured content in both contexts.
- Never use inline type imports.
- Always favor
@importsyntax at the top of JavaScript files for JSDoc types. - Add explicit TypeScript lib reference headers when a standalone example file relies on browser or service-worker globals, such as
/// <reference lib="dom" />for client files or/// <reference lib="webworker" />for service-worker files. - This repo does not require TypeScript declaration builds during normal development.
- Type builds are only needed during publish time or when debugging types.
- After running a type build, clean up the generated build files and do not leave them sitting around.
- Use the cleanup scripts in
package.jsonfor generated type build files. - The generated
lib/defaults/default.root.layout.jsis versioned runtime code, not temporary declaration output; regenerate it withnpm run build:defaultsafter editing its TypeScript source and never remove it during cleanup. - Keep
test-cases/focused on checked-in example sites paired with acceptance tests that build through the public API and assert on outputs or expected build errors. - Example sites should be understandable by browsing their source files, not reconstructed from JavaScript strings embedded in tests.
- Put detailed behavioral and regression tests beside the subsystem they exercise under
lib/, even when they build temporary sites or run real watchers. - Keep public facade tests at the repository root and public TypeScript contract tests in
type-tests/. - Behavioral tests may copy example sites into temporary directories, but must not mutate checked-in fixtures or depend on another test's output directory.
- Keep test-only files out of published packages and declaration builds; see
test-cases/README.mdfor the test organization guidelines. - For formatting-only ESLint failures, use
npx eslint <path> --fixfor a quick targeted fix before rerunning lint. - When handling PR review comments, validate that each comment is correct before making changes; maintainer comments are almost always valid, but review bot comments may be wrong, and after addressing a comment, always reply with what was done.