@eventcatalog/core 4.1.3 → 4.1.5

package/dist/docs/development/guides/data/versioning-and-lifecycle/01-versioning.md

@@ -1,32 +0,0 @@
----
-sidebar_position: 6
-keywords:
-- versioning
-- services
-sidebar_label: Versioning
-title: Versioning
-description: Learn how to version data stores
----
-
-import AddedIn from '@site/src/components/MDX/AddedIn';
-
-<AddedIn version="2.59.0" />
-
-All content in EventCatalog can be versioned. This allows you to keep historic versions of content which can give context to users why things are changing.
-
-## How to version a data store
-
-1. Create a `/versioned` directory inside the `/containers` folder if one is not created already.
-1. Create a new folder with the version number inside the folder.
-    - Example: `/containers/OrdersDatabase/versioned/0.0.1`
-1. Copy contents into the new folder, it at least needs your index.mdx file.
-    - Example: `/containers/OrdersDatabase/versioned/0.0.1/index.mdx`
-    - Note: the version inside this index.mdx file would be `0.0.1`
-1. Bump the version of the `index.mdx` file in the route of the data store.
-    - Example `/containers/OrdersDatabase/index.mdx`, change the `version` to `0.0.2`
-
-## How to navigate to versions
-
-EventCatalog will automatically create links for you within your latest version of your document. Users will also be able to navigate to any version by adding the version in the url (e.g /docs/containers/OrdersDatabase/1.0.2 would load the 1.0.2 version of this data store).
-
-![Example](../../img/domains/versioned-data-store.png)

package/dist/docs/development/guides/data/versioning-and-lifecycle/02-changelog.md

@@ -1,57 +0,0 @@
----
-sidebar_position: 7
-keywords:
-    - changelog 
-    - data stores
-sidebar_label: Adding a changelog
-title: Data store changelogs 
-description: Adding changelogs to your data stores
----
-
-import AddedIn from '@site/src/components/MDX/AddedIn';
-
-<AddedIn version="2.59.0" />
-
-EventCatalog supports changelogs for [domains](/docs/domains), [services](/docs/services), [messages](/docs/messages) and [data stores](/docs/data).
-
-When you [version a data store](/docs/development/guides/data/versioning-and-lifecycle/versioning) in EventCatalog, you can also attach a `changelog.mdx` to that data store or versioned data store.
-
-### Adding a changelog
-
-1. Add a `changelog.mdx` to your data store (or versioned data store)
-    - example `/services/{Service Name}/containers/{DataStore}/changelog.mdx`
-    - versioned example `/services/{Service Name}/containers/{DataStore}/versioned/1.0.0/changelog.mdx`
-
-**Example**
-```md title="/docs/services/PaymentService/containers/PaymentDatabase/changelog.md"
----
-createdAt: 2024-08-01
-badges:
-    - content: New table added
-      backgroundColor: green
-      textColor: green
----
-
-### New Table added to the PaymentDatabase
-
-The PaymentDatabase now has a new table called `PaymentTransactions`.
-
-<!-- Other details about the change here -->
-
-``` 
-
-Navigate to your change log page for your data store (example [/docs/services/PaymentService/containers/PaymentDatabase/0.0.1/changelog](https://demo.eventcatalog.dev/docs/services/PaymentService/containers/PaymentDatabase/0.0.1/changelog)) or **click on the Changelog button** on your data store page.
-
-:::tip "What do add to your change log?"
-Changelogs are just markdown files, this allows you to add anything you want (e.g code blocks, tables)
-
-EventCatalog code blocks supports diffs, code labels which are great features for changelogs. You can [read more here](/docs/api/code-blocks).
-
-:::
-
-### Why add changelogs?
-
-Changelogs can provide your team with the context behind the reasons and choices for changes within your data store and also be used for auditing purposes.
-
-
-

package/dist/docs/development/guides/data/versioning-and-lifecycle/03-deprecating.md

@@ -1,71 +0,0 @@
----
-sidebar_position: 5
-keywords:
-- EventCatalog
-- services 
-- owners
-sidebar_label: Deprecating data stores  
-title: Deprecating data stores
-description: Deprecating data stores with EventCatalog.
----
-
-import AddedIn from '@site/src/components/MDX/AddedIn';
-
-<AddedIn version="2.59.0" />
-
-Any resource in EventCatalog can be deprecated or marked as deprecated.
-
-This will show a banner on the page indicating that the resource is deprecated.
-
-## Deprecating data stores using frontmatter
-
-To deprecate a data store you need to add the `deprecated` field to the data store frontmatter API.
-
-This accepts a `boolean` or an `object` with the following properties:
-
-- `date`: Date the service will be or was deprecated (YYYY-MM-DD)
-- `message`: Reason the service is deprecated, supports markdown (optional)
-
-```md title="/services/OrderService/containers/OrderDatabase/index.mdx (example)"
----
-id: OrderDatabase
-... # other data store frontmatter
-
-# deprecated as an object (Recommended)
-deprecated:
-  # Date the data store will be or was deprecated (YYYY-MM-DD)
-  date: 2025-01-01
-  # Reason the data store is deprecated, supports markdown (optional)
-  message: | 
-    This data store has been deprecated and replaced by the new data store **OrderDatabaseV2**.
-    Please contact the [team for more information](mailto:inventory-team@example.com) or visit our [website](https://eventcatalog.dev).
-
-# deprecated as a boolean 
-deprecated: true
----
-
-```
-
-Configuration:
-
-- `deprecated`: `boolean` or `object`
-
-Deprecated as an object is recommended, as it gives your users more information to why the resource is deprecated and a date in the past or future.
-
-- `deprecated.date`: Date the data store will be or was deprecated (YYYY-MM-DD)
-- `deprecated.message`: Reason the data store is deprecated, supports markdown (optional)
-
-
-#### Rendered output
-
-Example of resource that will be deprecated:
-
-![Deprecating services](../../img/deprecated/will-be-deprecated-data-store.png) 
-
-Example of resource that is deprecated:
-
-![Deprecating services](../../img/deprecated/is-deprecated-data-store.png) 
-
-#### Demo
-
-You can see a demo of deprecating resources in the [EventCatalog demo site](https://demo.eventcatalog.dev/docs/services/InventoryService/0.0.2).

package/dist/docs/development/guides/data/versioning-and-lifecycle/_category_.json

@@ -1,11 +0,0 @@
-{
-  "label": "Versioning & lifecycle",
-  "position": 3,
-  "collapsible": true,
-  "collapsed": true,
-  "link": {
-    "type": "generated-index",
-    "slug": "/data/versioning-and-lifecycle",
-    "description": "A collection of guides to help you understand data versioning and lifecycle in EventCatalog."
-  }
-}

package/dist/docs/development/guides/data-products/02-adding-data-products.md

@@ -1,157 +0,0 @@
----
-sidebar_position: 2
-keywords:
-- EventCatalog data products
-sidebar_label: Creating a data product
-title: Creating data products
-description: Creating and managing data products
----
-
-import AddedIn from '@site/src/components/MDX/AddedIn';
-
-<AddedIn version="3.8.0" />
-
-Data products document analytical datasets that transform operational (e.g databases, messages, channels) data into insights. Adding a data product helps teams understand data lineage, contracts, and consumption patterns.
-
-### What do data products look like?
-
-![Example](./img/data-product.png)
-
-## Creating a data product
-
-Create a new folder called `data-products` and add your data product files to it.
-
-- `**/data-products/{DataProduct Name}/index.mdx`
-  - (example `**/data-products/OrderAnalytics/index.mdx`)
-  - (example `**/data-products/PaymentMetrics/index.mdx`)
-
-Data products can be defined in any folder. This lets you group data products by domains, teams, or business areas.
-
-### Creating the data product file
-
-Within your data product folder create an `index.mdx` file.
-
-The `index.mdx` contents split into two sections: **frontmatter** and **markdown content**.
-
-Here is an example data product markdown file. [You can read the API docs for the data product frontmatter API](/docs/api/data-product-api).
-
-```md title="/data-products/OrderAnalytics/index.mdx (example)"
----
-# Unique identifier for your data product
-id: order-analytics
-
-# Display name rendered in EventCatalog
-name: Order Analytics
-
-# Version of the data product
-version: 1.0.0
-
-# Brief summary of what this data product provides
-summary: Aggregated order metrics and KPIs for business intelligence
-
-# Optional owners (references teams or users)
-owners:
-  - dboyne
-
-# Optional badges for categorization
-badges:
-  - content: Analytics
-    backgroundColor: purple
-    textColor: purple
-  - content: dbt
-    backgroundColor: orange
-    textColor: orange
-
-# Input dependencies (events, services, data stores)
-inputs:
-  - id: OrderConfirmed
-    # version is optional for all inputs
-    version: 1.0.0
-  - id: PaymentProcessed
-  - id: payment-cache
-
-# Output data products (events, services, data stores)
-outputs:
-  - id: OrderMetricsCalculated
-    # version is optional for all outputs
-    version: 1.0.0
-  - id: NotificationService
-  - id: orders-db
-    contract:
-      path: fact-orders-contract.json
-      name: Fact Orders Contract
-      type: json-schema
----
-
-## Overview
-
-The Order Analytics data product transforms raw order and payment events into aggregated metrics optimized for reporting and business intelligence.
-
-<NodeGraph />
-
-Rest of your markdown....
-```
-
-**That's it!**
-
-Once you add your data product to EventCatalog, it will appear in the catalog.
-
-With **data products** you can write any Markdown and it will render on your page. Every data product gets its own page.
-
-Within your markdown content you can use [components](/docs/development/components/using-components) to add interactive elements.
-
-You can [see examples on GitHub](https://github.com/event-catalog/eventcatalog/tree/main/examples/default).
-
-## Directory structure
-
-Data products can be placed anywhere in your catalog:
-
-```
-/data-products
-  /OrderAnalytics
-    index.mdx
-    fact-orders-contract.json
-  /PaymentMetrics
-    index.mdx
-    payment-contract.json
-
-/domains
-  /E-Commerce
-    /data-products
-      /CustomerSegmentation
-        index.mdx
-```
-
-## Using the NodeGraph component
-
-The `<NodeGraph />` component visualizes relationships between your data product and its inputs/outputs.
-
-```md
-<NodeGraph />
-```
-
-This component automatically renders based on the `inputs` and `outputs` defined in your frontmatter.
-
-## Custom icon
-
-<AddedIn version="3.28.1" />
-
-Set `styles.icon` in your frontmatter to display a custom icon on the data product. The icon appears in the visualiser node, sidebar navigation, page header, and search results.
-
-```md title="/data-products/OrderAnalytics/index.mdx (example)"
----
-id: order-analytics
-name: Order Analytics
-version: 1.0.0
-styles:
-  icon: /icons/analytics/clickhouse.svg
----
-```
-
-The value can be a path to a file in your catalog's `public/` folder (e.g. `/icons/analytics/clickhouse.svg`) or an absolute URL (e.g. `https://cdn.simpleicons.org/snowflake`).
-
-## Next steps
-
-- [Define inputs and outputs](/docs/development/guides/data-products/inputs-and-outputs)
-- [Add schema contracts](/docs/development/guides/data-products/contracts)
-- [Add data products to domains](/docs/development/guides/data-products/adding-to-domains)

package/dist/docs/development/guides/data-products/05-versioning.md

@@ -1,240 +0,0 @@
----
-sidebar_position: 5
-keywords:
-- EventCatalog data products
-sidebar_label: Versioning
-title: Versioning
-description: Version data products and track changes
----
-
-import AddedIn from '@site/src/components/MDX/AddedIn';
-
-<AddedIn version="3.8.0" />
-
-Data products follow semantic versioning to track schema changes, input/output modifications, and business logic updates.
-
-## Why version data products?
-
-Versioning helps teams:
-
-- Track schema evolution over time
-- Identify breaking changes before deployment
-- Support multiple versions simultaneously
-- Communicate changes to consumers
-- Maintain historical documentation
-
-## Semantic versioning
-
-Data products use semantic versioning with the format `MAJOR.MINOR.PATCH`.
-
-**MAJOR** version changes indicate breaking changes to outputs, schemas, or contracts.
-
-**MINOR** version changes add new outputs or non-breaking enhancements.
-
-**PATCH** version changes fix bugs or update documentation without affecting outputs.
-
-```md
----
-id: payment-analytics
-name: Payment Analytics
-version: 1.0.0  # MAJOR.MINOR.PATCH
----
-```
-
-## Creating versions
-
-Create a `versioned` folder within your data product directory to store previous versions.
-
-```
-/data-products
-  /PaymentAnalytics
-    index.mdx                    # Current version (1.2.0)
-    payment-contract.json
-    /versioned
-      /1.0.0
-        index.mdx
-        payment-contract.json
-      /1.1.0
-        index.mdx
-        payment-contract.json
-```
-
-The root `index.mdx` always represents the latest version.
-
-## Versioning workflow
-
-When making changes to a data product:
-
-1. Copy the current `index.mdx` and related files to a new versioned folder
-2. Update the version number in the root `index.mdx`
-3. Make your changes to the root files
-4. Document changes in the changelog
-
-```bash
-# Create new version folder
-mkdir -p data-products/PaymentAnalytics/versioned/1.1.0
-
-# Copy current files
-cp data-products/PaymentAnalytics/index.mdx data-products/PaymentAnalytics/versioned/1.1.0/
-cp data-products/PaymentAnalytics/payment-contract.json data-products/PaymentAnalytics/versioned/1.1.0/
-
-# Update root version
-# Edit index.mdx: version: 1.2.0
-```
-
-## Breaking changes
-
-Breaking changes require a major version bump and clear communication to consumers.
-
-Examples of breaking changes:
-
-- Removing or renaming output fields
-- Changing field types
-- Removing outputs
-- Modifying contract requirements
-- Changing input dependencies significantly
-
-```md title="Breaking change example"
----
-id: payment-analytics
-version: 2.0.0  # Major version bump
-summary: Breaking change - renamed fraud_score to risk_score
----
-
-## Breaking Changes in v2.0.0
-
-- **Renamed field**: `fraud_score` → `risk_score`
-- **Removed field**: `legacy_status` (deprecated in v1.5.0)
-- **Type change**: `transaction_date` now returns ISO 8601 format
-```
-
-## Non-breaking changes
-
-Minor versions add functionality without breaking existing consumers.
-
-Examples of non-breaking changes:
-
-- Adding new output fields
-- Adding new outputs
-- Adding new inputs
-- Enhancing documentation
-- Adding optional filters or parameters
-
-```md title="Non-breaking change example"
----
-id: payment-analytics
-version: 1.3.0  # Minor version bump
-summary: Added chargeback metrics to output schema
----
-
-## What's New in v1.3.0
-
-- **New field**: `chargeback_rate` added to output schema
-- **New output**: `ChargebackAlert` event for high-risk transactions
-```
-
-## Version references
-
-When referencing data products from other resources, you can pin to specific versions or use `latest`.
-
-```md title="Service referencing data product"
----
-id: reporting-service
-name: Reporting Service
-version: 1.0.0
-
-# Pin to specific version
-inputs:
-  - id: payment-analytics
-    version: 1.2.0
-
-# Use latest version (default)
-inputs:
-  - id: order-analytics
-    version: latest
----
-```
-
-Omitting the version defaults to `latest`:
-
-```md
-inputs:
-  - id: payment-analytics  # Defaults to latest
-```
-
-## Changelog
-
-Document version changes in a `changelog.mdx` file within your data product directory.
-
-```
-/data-products
-  /PaymentAnalytics
-    index.mdx
-    changelog.mdx
-    payment-contract.json
-```
-
-```md title="changelog.mdx"
----
-createdAt: 2026-01-15
----
-
-## 1.3.0
-
-### Added
-- Chargeback metrics to output schema
-- ChargebackAlert event for high-risk transactions
-
-### Changed
-- Improved fraud detection model accuracy
-
-## 1.2.0
-
-### Added
-- Revenue attribution by channel
-- Gateway performance metrics
-
-### Fixed
-- Currency conversion edge cases
-
-## 1.1.0
-
-### Added
-- Real-time payment success rate
-- Authorization rate metrics
-
-## 1.0.0
-
-Initial release of Payment Analytics data product.
-```
-
-EventCatalog automatically links changelogs to data product pages.
-
-## Deprecation
-
-Mark data products as deprecated when planning to sunset them.
-
-```md
----
-id: payment-analytics-v1
-version: 1.0.0
-deprecated:
-  message: Migrate to PaymentAnalyticsV2 for improved performance
-  date: 2026-06-01
-badges:
-  - content: Deprecated
-    backgroundColor: red
-    textColor: red
----
-
-:::warning Deprecation Notice
-
-This data product will be sunset on June 1, 2026. Migrate to PaymentAnalyticsV2.
-
-:::
-```
-## Next steps
-
-- [Add to domains](/docs/development/guides/data-products/adding-to-domains)
-- [Changelog documentation](/docs/development/guides/changelogs/introduction)
-- [Data product API reference](/docs/api/data-product-api)

package/dist/docs/development/guides/data-products/06-adding-to-domains.md

@@ -1,52 +0,0 @@
----
-sidebar_position: 6
-keywords:
-  - EventCatalog data products
-sidebar_label: Adding to domains
-title: Adding to domains
-description: Organize data products within domains
----
-
-import AddedIn from '@site/src/components/MDX/AddedIn';
-
-<AddedIn version="3.8.0" />
-
-Data products can be placed anywhere in your catalog, but we recommend organizing them within domain folders for better clarity and ownership.
-
-## Adding data products to domains
-
-You can create data products in any directory structure you prefer. We recommend placing them in your domain folder:
-
-```
-/domains
-  /E-Commerce
-    index.mdx
-    /data-products
-      /OrderAnalytics
-        index.mdx
-      /PaymentAnalytics
-        index.mdx
-```
-
-Then reference them in your domain's frontmatter:
-
-```md title="/domains/E-Commerce/index.mdx"
----
-id: e-commerce
-name: E-Commerce
-version: 1.0.0
-
-data-products:
-  - id: order-analytics
-  - id: payment-analytics
-    # version is optional for all data products
-    version: 1.0.0
----
-```
-
-This associates the data products with your domain and displays them on the domain page.
-
-## Next steps
-
-- [Domain documentation](/docs/development/guides/domains/introduction)
-- [Data product API reference](/docs/api/data-product-api)

package/dist/docs/development/guides/diagrams/01-introduction.md

@@ -1,78 +0,0 @@
----
-sidebar_position: 1
-keywords:
-- EventCatalog diagrams
-- Architecture diagrams
-- Custom diagrams
-- Mermaid
-- PlantUML
-- Miro
-- IcePanel
-sidebar_label: Understanding diagrams
-title: Understanding diagrams
-description: Bring your own diagrams to EventCatalog - version them, compare them, and assign them to any resource
----
-
-import AddedIn from '@site/src/components/MDX/AddedIn';
-
-<AddedIn version="3.3.0" />
-
-EventCatalog automatically generates architecture diagrams based on your resources and how they relate to each other. These auto-generated visualizations help you understand your system's structure.
-
-**But what about your own diagrams?**
-
-Many teams have existing architecture diagrams - whether they're Mermaid flowcharts, PlantUML sequence diagrams, Miro boards, IcePanel views, or simple images. The diagrams feature lets you bring these into EventCatalog as first-class, versioned resources.
-
-### What can you do with diagrams?
-
-With diagrams in EventCatalog you can:
-
-- **Bring any diagram type** - Mermaid, PlantUML, Miro embeds, IcePanel, Lucidchart, draw.io, images, or any MDX content
-- **Version your diagrams** - Track how your architecture visualizations evolve over time
-- **Compare versions side-by-side** - See what changed between diagram versions (Scale feature)
-- **Assign to any resource** - Link diagrams to domains, services, messages, or containers
-- **Reuse across resources** - Reference the same diagram from multiple places in your catalog
-- **Organize flexibly** - Store diagrams at the top level or nest them within domains and services
-- **Ask questions with AI** - Use EventCatalog's AI assistant to ask questions about your diagrams
-- **Expose to LLMs** - Diagrams are available at `.mdx` URLs (e.g., `/diagrams/my-diagram/1.0.0.mdx`) for LLM consumption
-
-### How is this different from auto-generated diagrams?
-
-| Auto-generated diagrams | Custom diagrams (this feature) |
-|------------------------|-------------------------------|
-| Created automatically from your resources | You create and maintain them |
-| Show relationships between catalog items | Show anything you want |
-| Update when resources change | Update when you version them |
-| Limited to catalog data | Any visual content |
-
-Both complement each other. Auto-generated diagrams show your system as documented in the catalog. Custom diagrams let you add context - migration plans, target architectures, sequence flows, event storming results, or embedded boards from your favorite diagramming tools.
-
-### What do diagrams look like in EventCatalog?
-
-Diagrams have their own dedicated pages with version switching and appear in the sidebar when assigned to resources.
-
-![Diagram page](./img/diagrams.png)
-
-[View Demo of a Target Architecture diagram &rarr;](https://demo.eventcatalog.dev/diagrams/target-architecture/1.0.0)
-
-### When to use custom diagrams
-
-Use diagrams when you want to:
-
-- Document target architecture or migration plans
-- Embed Miro boards, IcePanel views, or other collaborative diagrams
-- Create sequence diagrams showing detailed message flows
-- Share event storming results or architecture decision records
-- Maintain historical versions of architectural diagrams
-- Add visual context that can't be auto-generated from your resources
-
-### Supported content formats
-
-Diagrams support any content you can write in MDX:
-
-- **Mermaid diagrams** - Flowcharts, sequence diagrams, C4 diagrams
-- **PlantUML diagrams** - UML, sequence, component diagrams
-- **Embedded diagrams** - Miro, IcePanel, Lucidchart, draw.io, FigJam
-- **Static images** - PNG, SVG, JPG files
-- **Markdown content** - Add explanations and documentation around visuals
-- **Custom components** - Use any MDX component to enhance your diagrams