Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 11 additions & 0 deletions CLAUDE.md
Original file line number Diff line number Diff line change
Expand Up @@ -419,6 +419,16 @@ APIs use `Asp.Versioning.Mvc`:
- Delivery API: `/umbraco/delivery/api/v{version}/*`
- OpenAPI/Swagger docs per version

### Updating `OpenApi.json` (Management API)
Copy link
Copy Markdown
Member

@madsrasmussen madsrasmussen Apr 1, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like a perfect fit for a skill, and not something that is needed in general knowledge.

Should we also include steps to generate the client-side SDK?


When a PR changes Management API controllers or models, the `OpenApi.json` file in the Management API project must be updated:

1. Run the Umbraco instance locally
2. Open Swagger UI and navigate to the swagger.json link (e.g. `https://localhost:44339/umbraco/swagger/management/swagger.json`)
3. Copy the full JSON content and paste it into `src/Umbraco.Cms.Api.Management/OpenApi.json`

**Important**: Commit only the substantive changes — not IDE-applied formatting (whitespace, reordering, etc.). Extraneous formatting diffs make PRs harder to review and merge-ups more error-prone.

### Backoffice npm Package

The backoffice is published to npm as `@umbraco-cms/backoffice`. Runtime dependencies are provided via importmap; npm peerDependencies provide types only. For full details on dependency hoisting, version range logic, and plugin development, see `/src/Umbraco.Web.UI.Client/CLAUDE.md` → "npm Package Publishing".
Expand Down Expand Up @@ -461,6 +471,7 @@ The `Tests:Database:DatabaseType` setting controls which database is used:
- `"LocalDb"` - Uses SQL Server LocalDB, required for SQL Server-specific tests (e.g., page-level locking, `sys.dm_tran_locks`)

SQL Server-specific tests use `BaseTestDatabase.IsSqlite()` to skip when running on SQLite.

### Key Projects

| Project | Type | Description |
Expand Down
17 changes: 17 additions & 0 deletions src/Umbraco.Web.UI.Client/docs/clean-code.md
Original file line number Diff line number Diff line change
Expand Up @@ -462,6 +462,23 @@ export class UmbDocumentActionButton extends LitElement {
- Remove unused imports, functions, variables
- Clean up console.logs before committing

### Feature Parity with Core Equivalents
Copy link
Copy Markdown
Member

@madsrasmussen madsrasmussen Apr 1, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we will have to rethink or remove this paragraph.

We are currently trying to make agents treat the documentation files as the source of truth and only secondarily look for similar implementations in the codebase. This paragraph might end up confusing the agent 🤔

My suggestion is to add specific documentation for the area this should cover. Please see how it is already done for other client-side concepts and extensions: concept and pattern explanations in the documentation, followed by guided implementation steps in a skill.


When implementing a new component that mirrors an existing core or sibling implementation (e.g. a new collection action alongside document/media/member equivalents), do a side-by-side comparison against the core version before considering it done.

**Checklist**:

1. **Full API surface**: Read the reference implementation's controller/API usage line by line. Every method call, callback, and property access on controllers in the reference must have a counterpart in the new implementation — don't cherry-pick only the obvious ones.
2. **Error handling**: Match the core's error handling pattern (e.g. `.catch(() => {})` on `execute()` calls) to prevent unhandled promise rejections.
3. **Type hierarchy**: Before defining new interfaces, search for existing base types (e.g. `UmbNamedEntityModel` vs `UmbEntityModel`) that already declare the fields you need. Use the most specific base.
4. **UI consistency**: Check CSS from sibling implementations (e.g. `max-height` on scroll containers, icon fallbacks like `?? 'icon-document'`).
5. **Context-appropriate strings**: Don't reuse localization keys from another domain (e.g. `create_noDocumentTypes` in an elements context). Either create a new key or use only the inline fallback text.

**Core components to compare against** (common patterns):
- Collection create actions: `src/packages/core/collection/action/create/collection-create-action.element.ts`
- Entity create option modals: `src/packages/core/entity-action/common/create/modal/entity-create-option-action-list-modal.element.ts`
- Document/media/member equivalents in their respective `src/packages/` directories

### Patterns to Avoid

**Don't**:
Expand Down
10 changes: 10 additions & 0 deletions src/Umbraco.Web.UI.Client/docs/style-guide.md
Original file line number Diff line number Diff line change
Expand Up @@ -196,6 +196,16 @@ export class UmbBadElement extends LitElement {
- `@cssprop` - CSS custom properties
- `@csspart` - CSS parts

### Third-Party Library Names

Use the correct capitalization for third-party libraries:

| Library | Correct | Incorrect |
|---------|---------|------------------------|
| Tiptap | Tiptap | TipTap, tipTap, TIPTAP |
| Lit | Lit | LIT, lit (in prose) |
| RxJS | RxJS | rxjs (in prose), RXJS |

### Documentation

- **Public APIs**: JSDoc comments with `@description`, `@param`, `@returns`, `@example`
Expand Down
Loading