- Use
Idinstead ofIDfor all variable and property names. - This applies to code identifiers such as variables, properties, parameters, functions, and types.
- Examples: use
customerId,siteId,getEntityId, andtype EntityIdMap = ...; do not usecustomerID,siteID,getEntityID, ortype EntityIDMap = ....
- For local verification, prefer commands scoped to
packages/visual-editorinstead of root recursive scripts. - If a package or workspace is not specified, assume
packages/visual-editor. - After TypeScript changes, run
pnpm --dir packages/visual-editor exec tsc --noEmit. - For routine local tests, run
pnpm --dir packages/visual-editor run test:editor. - Do not use root
pnpm run testfor normal local verification. It expands into the packagetestscript, which includes component tests. - Do not use
pnpm run test:componentsas a normal local step. It is part of the Playwright screenshot workflow and is not expected to work directly on a normal local machine. - Only use
pnpm --dir packages/visual-editor run test:components:localwhen intentionally running screenshot/component tests with Docker.
- Treat
lint,prettier,autofix,i18n:update, and docs-generation commands as mutating commands. Run them only when the task calls for those changes. - If locale strings change, run
pnpm --dir packages/visual-editor run i18n:update.
packages/visual-editoris the primary package and the default place for library code changes.starteris primarily a local consumer app for development and integration testing; only work there when the task specifically involves the starter or local validation.- Public exports should go through the package entrypoints such as
packages/visual-editor/src/index.tsand related packageindex.tsfiles. - Do not export everything by default. Only add or keep public exports that are actually needed by consumers.
- Do not publicly export modules from
packages/visual-editor/src/internal. Keep the public API surface small and intentional. - Within
packages/visual-editor, prefer relative imports for internal code.
- Add a migration when a component is renamed, when component props change, when component fields or field options change in a way that could invalidate existing saved data, or when removing a component and existing layouts still need to be handled.
- If a migration is needed, add a new migration file and append it to
packages/visual-editor/src/components/migrations/migrationRegistry.ts. - Existing migrations are append-only and immutable. Do not rewrite or repurpose old migration files; add a new migration instead.