npm - @eventcatalog/core - Versions diffs - 4.2.2 → 4.2.4 - Mend

@eventcatalog/core 4.2.2 → 4.2.4

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (68) hide show

package/dist/analytics/analytics.cjs CHANGED Viewed

@@ -36,7 +36,7 @@ module.exports = __toCommonJS(analytics_exports);
 var import_os = __toESM(require("os"), 1);
 // package.json
-var version = "4.2.2";
+var version = "4.2.4";
 // src/constants.ts
 var VERSION = version;

package/dist/analytics/analytics.js CHANGED Viewed

@@ -1,7 +1,7 @@
 import {
   raiseEvent
-} from "../chunk-ZGQNCIRW.js";
-import "../chunk-A5LDEHRI.js";
+} from "../chunk-BXEGST4Z.js";
+import "../chunk-J2MVHSKA.js";
 export {
   raiseEvent
 };

package/dist/analytics/log-build.cjs CHANGED Viewed

@@ -140,7 +140,7 @@ var verifyRequiredFieldsAreInCatalogConfigFile = async (projectDirectory) => {
 var import_os = __toESM(require("os"), 1);
 // package.json
-var version = "4.2.2";
+var version = "4.2.4";
 // src/constants.ts
 var VERSION = version;

package/dist/analytics/log-build.js CHANGED Viewed

@@ -1,9 +1,9 @@
 import {
   log_build_default
-} from "../chunk-HIQ22EHS.js";
+} from "../chunk-GCEFDCZB.js";
 import "../chunk-K2XIENVT.js";
-import "../chunk-ZGQNCIRW.js";
-import "../chunk-A5LDEHRI.js";
+import "../chunk-BXEGST4Z.js";
+import "../chunk-J2MVHSKA.js";
 import "../chunk-6QENHZZP.js";
 export {
   log_build_default as default

package/dist/{chunk-Z2CMR4HM.js → chunk-5MIGBCON.js} RENAMED Viewed

@@ -1,6 +1,6 @@
 import {
   VERSION
-} from "./chunk-A5LDEHRI.js";
+} from "./chunk-J2MVHSKA.js";
 // src/utils/cli-logger.ts
 import pc from "picocolors";

package/dist/{chunk-ZGQNCIRW.js → chunk-BXEGST4Z.js} RENAMED Viewed

@@ -1,6 +1,6 @@
 import {
   VERSION
-} from "./chunk-A5LDEHRI.js";
+} from "./chunk-J2MVHSKA.js";
 // src/analytics/analytics.js
 import os from "os";

package/dist/{chunk-HIQ22EHS.js → chunk-GCEFDCZB.js} RENAMED Viewed

@@ -4,7 +4,7 @@ import {
 } from "./chunk-K2XIENVT.js";
 import {
   raiseEvent
-} from "./chunk-ZGQNCIRW.js";
+} from "./chunk-BXEGST4Z.js";
 import {
   getEventCatalogConfigFile,
   verifyRequiredFieldsAreInCatalogConfigFile

package/dist/{chunk-A5LDEHRI.js → chunk-J2MVHSKA.js} RENAMED Viewed

@@ -1,5 +1,5 @@
 // package.json
-var version = "4.2.2";
+var version = "4.2.4";
 // src/constants.ts
 var VERSION = version;

package/dist/{chunk-JV33GNVZ.js → chunk-WVIOZDVK.js} RENAMED Viewed

@@ -1,6 +1,6 @@
 import {
   logger
-} from "./chunk-Z2CMR4HM.js";
+} from "./chunk-5MIGBCON.js";
 import {
   cleanup,
   getEventCatalogConfigFile

package/dist/constants.cjs CHANGED Viewed

@@ -25,7 +25,7 @@ __export(constants_exports, {
 module.exports = __toCommonJS(constants_exports);
 // package.json
-var version = "4.2.2";
+var version = "4.2.4";
 // src/constants.ts
 var VERSION = version;

package/dist/constants.js CHANGED Viewed

@@ -1,6 +1,6 @@
 import {
   VERSION
-} from "./chunk-A5LDEHRI.js";
+} from "./chunk-J2MVHSKA.js";
 export {
   VERSION
 };

package/dist/docs/development/00-why-eventcatalog.md CHANGED Viewed

@@ -18,33 +18,33 @@ As systems grow, complexity grows. Documentation becomes important for teams but
 ### What is EventCatalog?
-EventCatalog is a documentation and governance tool that is built for architects.
+EventCatalog is an open source documentation tool that is built for software architecture.
- It lets you document and visualize your architecture with primitives you are already familiar with. You can document domains, systems, applications and schemas and visualize how they all relate to each other.
+We focus on architecture primitives like domains, systems and resources (e.g services, messages) and let you document your architecture with primitives you are already familiar with.
 EventCatalog creates an internal architecture graph of how your systems work. This makes EventCatalog accessible to your AI agents, LLMs and AI workflows and [creates context of your business and architecture](/docs/development/ask-your-architecture/intro).
-EventCatalog is technology agnostic, this means you can document and model any systems you have
+EventCatalog is technology agnostic, this means you can document and model any systems you have.
-#### What can EventCatalog do for you?
+#### Our project goals for you
-- **Save time across the organization**
+- **Help you save time across the organization**
   - Help teams find information they need across your business and organization
   - Document high level information for stakeholders while providing lower level details to your teams.
   - Connect to your AI Agents and AI Workflows. Give your LLMs the context they need.
-- **Create documentation you can trust**
+- **Create a documentation solution you can trust**
   - Sync documentation from your code with our Agent
   - Automate documentation from your OpenAPI, AsyncAPI, or schema registries
   - Use EventCatalog Agent to sync code to docs from your CI/CD workflows.
   - Write your own automation and plugins with the [EventCatalog SDK](/docs/sdk)
-- **Detect breaking changes before they reach production**
+- **Help you detect breaking changes before they reach production**
   - Use EventCatalog Agent to detect breaking schema changes
   - Bring your own model and get notified when things break
 - **Use natural langugage to query your architecture**
   - Connect AI tools to your architecture using [EventCatalog's MCP server](/docs/development/ask-your-architecture/mcp-server/introduction)
   - Ask architectural questions grounded in your documented domains, services, events, data products, and schemas
-- **Show the bigger picture**
+- **Help your teams understand the bigger picture**
   - Help business stakeholders understand the bigger picture
   - Visualize your architecture and future ideas
   - Document key business workflows

package/dist/docs/development/01-fundamentals.md CHANGED Viewed

@@ -8,27 +8,28 @@ title: Fundamentals
 description: Understanding the fundamentals of EventCatalog
 ---
-EventCatalog is a architecture catalog built around software primitives and domain-driven design patterns, so you can model the systems you actually build instead of creating disconnected documentation pages.
+EventCatalog is a self hosted [open source documentation tool](https://github.com/event-catalog/eventcatalog/stargazers) for software architecture. It allows you to document your architecture using software primitives and patterns such as domains, systems and resources rather than random documentation pages (e.g Confluence).
-EventCatalog gives your teams and AI agents a shared understanding of how your systems work across your organization.
+EventCatalog follows the [docs-as-code](https://www.writethedocs.org/guide/docs-as-code/) pattern. Your documentation is stored in code using [markdown (MDX)](https://mdxjs.com/) and stays private, in your own repository and infrastructure.
-EventCatalog is an open source project and is self-hosted and follows the [docs-as-code](https://www.writethedocs.org/guide/docs-as-code/) pattern. All pages in EventCatalog are powered by [markdown (MDX)](https://mdxjs.com/).
+At its core, EventCatalog gives you a small set of building blocks for your documentation.
-Your catalog is private, stays in your own repository and infrastructure.
-At its core, EventCatalog gives you a small set of building blocks.
+![EventCatalog model showing domains, systems, resources, contracts, and ownership](./img/levels-catalog.png)
 - **Domains (Level 1)** - a domain describes a business boundary
 - **Systems (Level 2)** - a system is a collection of resources that work together to perform a function.
 - **Resources (Level 3)** - individual resources (e.g services, messages, data stores) that can be assigned to systems or domains.
-All building blocks are optional, it's up to you how you want to model your architecture in your catalog.
+:::info What blocks to use?
+All building blocks are optional in your catalog. It's up to you how you want to model your documentation.
-![EventCatalog model showing domains, systems, resources, contracts, and ownership](./img/ec-types.png)
+Want to match your c4 model?, you can. Want to document a monolith you can. Want to document distributed systems you can.
+We focus on architecture primitives and let you fill in the details.
+:::
 ## The EventCatalog model
-Domains give your catalog a business shape. They help users understand the boundaries in your architecture, such as `Shopping`, `Payments`, `Fulfilment`, or `Customer`.
+Domains describe a business capability or boundary. They help users understand the boundaries in your architecture, such as `Shopping`, `Payments`, `Fulfilment`, or `Customer`.
 Systems give your catalog an operating shape. A system is a collection of resources that work together to perform a function. For example, a `Shopping` domain might contain a `Cart System` and a `Promotion System`.
@@ -48,7 +49,9 @@ Teams and users can own domains, systems, resources, and contracts. This makes o
 ## Levels of detail
-EventCatalog is useful to anyone in your organization. You can define high level primitives whilst giving lower level implementation details.
+Architecture documentation all have different audiences, and EventCatalog can be useful to anyone in your organization.
+You can define a high level of information for stakeholders whilst whilst giving lower level implementation details for developers.
 | Level | Name | What it answers | Example |
 |-------|------|-----------------|---------|
@@ -76,9 +79,9 @@ It's up to you where you define your catalog (or catalogs). Here are some exampl
 | **Federated** | Multiple EventCatalog instances connected into one view |
-## Automation
+## Living documentation
-Your documentation can also be automated, keeping your implementation details close to your documentation. There are many [integrations](/integrations) or you can create your own automations with our [SDK](/docs/sdk).
+Your documentation can also be automated, keeping your implementation details close to your documentation. There are many [integrations](/integrations) or you can create your own automations with our [SDK](/docs/sdk). We also have started building some [AI Agents to help you manage your documentation](https://github.com/event-catalog/agents) in CI/CD environments.
 ## Visual editing

package/dist/docs/development/bring-your-own-documentation/diagrams/07-reference.md CHANGED Viewed

@@ -142,3 +142,7 @@ attachments:
 ## Content
 Diagram pages can contain any MDX supported by EventCatalog, including Mermaid, PlantUML, Miro, IcePanel, Lucid, Draw.io, FigJam, images, and normal markdown.
+## Custom properties
+You can add organization-specific metadata to this resource using frontmatter fields prefixed with `x-`. Learn how to define, render, and reference them in [Custom properties on resources](/docs/development/customization/custom-properties).

package/dist/docs/development/components/components/07-custom-properties.md ADDED Viewed

@@ -0,0 +1,85 @@
+---
+sidebar_position: 7
+keywords:
+- components
+- custom properties
+- resource metadata
+sidebar_label: CustomProperties
+title: CustomProperties
+description: Render custom x-* resource properties in EventCatalog.
+---
+import AddedIn from '@site/src/components/MDX/AddedIn';
+<AddedIn version="4.3.0" />
+`<CustomProperties />` and `<CustomProperty />` render organization-specific `x-*` properties from the current resource.
+Both are built-in components, so you can use them in resource MDX without importing them.
+Read [Custom properties on resources](/docs/development/customization/custom-properties) to learn how to define `x-*` properties and reference them from MDX or your own components.
+## Render all custom properties
+Add custom properties to the resource frontmatter, then add `<CustomProperties />` to its Markdown content.
+```jsx title="/adrs/adr-001-use-transactional-outbox/index.mdx"
+---
+id: adr-001-use-transactional-outbox
+name: 'ADR-001: Publish product events via a transactional outbox'
+version: 1.0.0
+status: accepted
+date: 2026-02-10
+x-next-review-date: '2027-02-10'
+x-risk-level: medium
+---
+## Context
+The Product Catalog System publishes product changes through a transactional outbox.
+<CustomProperties title="Review metadata" />
+```
+### Output
+![CustomProperties rendering review metadata on an architecture decision record](/img/docs/components/custom-properties.png)
+Property names are converted into readable labels. For example, `x-next-review-date` is displayed as **Next Review Date**. The information icon beside each label shows the original `x-*` property name.
+Strings, numbers, and booleans are rendered directly. Arrays are rendered as bullet lists, and nested objects are rendered recursively as grouped values.
+### CustomProperties props
+| Name | Type | Default | Description |
+| --- | --- | --- | --- |
+| `title` | `string` | `Custom properties` | Heading displayed above the properties table. Pass an empty string to hide the heading. |
+## Render one custom property
+Use `<CustomProperty />` when you only want to render one `x-*` value.
+```mdx
+<CustomProperty name="x-risk-level" />
+```
+Use `label` to override the generated property label.
+```mdx
+<CustomProperty name="x-next-review-date" label="Review again on" />
+```
+If the named property is not defined on the current resource, the component renders nothing.
+### CustomProperty props
+| Name | Type | Required | Description |
+| --- | --- | --- | --- |
+| `name` | `string` | Yes | Name of the `x-*` property to render. |
+| `label` | `string` | No | Label displayed for the property. By default, EventCatalog generates a label from `name`. |
+## Support
+`<CustomProperties />` and `<CustomProperty />` are supported on domains, systems, services, agents, events, commands, queries, channels, flows, containers, entities, data products, diagrams, and ADRs.
+The components require an `.mdx` resource file. Plain `.md` files do not evaluate MDX components.

package/dist/docs/development/components/components/{07-design.md → 08-design.md} RENAMED Viewed

@@ -1,5 +1,5 @@
 ---
-sidebar_position: 7
+sidebar_position: 8
 keywords:
 - components
 - remote schema

package/dist/docs/development/components/components/{08-entitymap.md → 09-entitymap.md} RENAMED Viewed

@@ -1,5 +1,5 @@
 ---
-sidebar_position: 8
+sidebar_position: 9
 keywords:
 - components
 sidebar_label: EntityMap
@@ -68,4 +68,4 @@ If you want to render a subset of the entities in the map, you can use the `enti
 In this example, only the `Order` and `Customer` entities will be chosen to be rendered in the map.
-If the `Order` or `Customer` entity references other entities, they will also be rendered in the map
+If the `Order` or `Customer` entity references other entities, they will also be rendered in the map

package/dist/docs/development/components/components/{09-flow.md → 10-flow.md} RENAMED Viewed

@@ -1,5 +1,5 @@
 ---
-sidebar_position: 9
+sidebar_position: 10
 keywords:
 - components
 sidebar_label: Flow

package/dist/docs/development/components/components/{10-link.md → 11-link.md} RENAMED Viewed

@@ -1,5 +1,5 @@
 ---
-sidebar_position: 10
+sidebar_position: 11
 keywords:
 - components
 sidebar_label: Link

package/dist/docs/development/components/components/{11-mermaid-file-loader.md → 12-mermaid-file-loader.md} RENAMED Viewed

@@ -1,5 +1,5 @@
 ---
-sidebar_position: 11
+sidebar_position: 12
 keywords:
 - components
 - remote schema

package/dist/docs/development/components/components/{12-message-table.md → 13-message-table.md} RENAMED Viewed

@@ -1,5 +1,5 @@
 ---
-sidebar_position: 12
+sidebar_position: 13
 keywords:
 - components
 sidebar_label: MessageTable

package/dist/docs/development/components/components/{13-nodegraph.md → 14-nodegraph.md} RENAMED Viewed

@@ -1,5 +1,5 @@
 ---
-sidebar_position: 13
+sidebar_position: 14
 keywords:
 - components
 sidebar_label: NodeGraph
@@ -167,4 +167,3 @@ You can see a demo of this [here](https://demo.eventcatalog.dev/docs/domains/E-C