@eventcatalog/core 5.8.0 → 5.9.1

package/dist/docs/development/ask-your-architecture/07-catch-breaking-changes.md

@@ -0,0 +1,149 @@
+---
+sidebar_position: 7
+keywords:
+  - Breaking Changes
+  - EventCatalog Agents
+  - schema governance
+  - schema compatibility
+  - GitHub Actions
+sidebar_label: Catch breaking changes
+title: Catch breaking changes
+description: The Breaking Changes workflow comments on pull requests when a schema change would break a consumer documented in your EventCatalog, with the consumers and their owners.
+slug: /development/agents/set-up-breaking-changes
+---
+
+import { BreakingChangesComment } from '@site/src/components/AgentOutputs';
+import { AgentPrompt } from '@site/src/components/AgentPrompt';
+
+The **Breaking Changes** workflow checks the message schemas changed in a pull request. If a change would break consumers documented in your catalog, it comments with what breaks, who is affected, and who owns them, before the change merges. It never edits your catalog.
+
+<AgentPrompt variant="breaking-changes" />
+
+<BreakingChangesComment />
+
+## How it works
+
+1. **Finds changed schemas.** It looks for changed schema files in the pull request.
+2. **Checks each change.** A change is breaking when existing consumers could fail: a removed or renamed field, a changed type, a new required field, a narrowed enum, and similar. Additive changes, such as a new optional field, are not breaking.
+3. **Finds the consumers.** It matches the schema to its message in your catalog, then finds every service, agent or domain that receives it at an affected version.
+4. **Comments on the pull request** with the breaking lines and each consumer with its owners.
+
+If the pull request changes no schemas, or none of the changes are breaking, it doesn't comment. If a breaking change has no consumers in your catalog, the comment says so.
+
+A consumer is affected when it receives the message at its current version, at `latest` or with no version, or at a range that includes the current version, such as `1.x`. Consumers pinned to an older version are listed too, with their version. The reason given for each consumer comes from your catalog, such as "Receives payment-succeeded 1.0.0". The agent doesn't guess how a consumer uses particular fields.
+
+## Before you start
+
+You need:
+
+- An EventCatalog in a GitHub repository (the **catalog repository**), with the catalog at the root of the repository, and the consumers of your messages documented in it.
+- A repository with message schemas (the **source repository**).
+- An API key for an AI model provider.
+
+## Setup
+
+In your source repository, add two secrets under **Settings → Secrets and variables → Actions**:
+
+- `ANTHROPIC_API_KEY`, or the key for [your model provider](#models).
+- `EVENTCATALOG_TOKEN`, a GitHub token that can read your catalog repository. The workflow never writes to it.
+
+Then add the workflow. It runs while the pull request is open, so the warning arrives before the change merges:
+
+```yaml title=".github/workflows/eventcatalog-breaking-changes.yml"
+on:
+  pull_request:
+    types: [opened, synchronize, reopened]
+
+jobs:
+  breaking-changes:
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+      issues: write
+      pull-requests: write
+    steps:
+      - uses: actions/checkout@v6
+        with:
+          ref: ${{ github.event.pull_request.head.sha }}
+          fetch-depth: 0
+      - uses: event-catalog/agents@v2
+        env:
+          # The key for your model's provider. This one is for the default model.
+          # Using another provider? Swap this variable and set `model` below.
+          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
+        with:
+          # The agent workflow to run.
+          agent: breaking-changes
+          # Your catalog repository, in owner/repo format.
+          catalog-repo: your-org/your-catalog
+          # A token that can read your catalog repository.
+          catalog-token: ${{ secrets.EVENTCATALOG_TOKEN }}
+          # Optional: the model to use. Defaults to anthropic/claude-sonnet-4-6.
+          # model: openai/gpt-5.1
+```
+
+Replace `your-org/your-catalog` with your catalog repository. Keep `fetch-depth: 0`: the agent needs it to compare the pull request with its base branch.
+
+To check it works, open a pull request that removes a field from a schema that a service in your catalog consumes.
+
+If you also [sync docs with your code](/docs/development/agents/set-up-code-to-docs), you can run both from one workflow file: add `closed` to the `types`, and give each job an `if`:
+
+```yaml
+on:
+  pull_request:
+    types: [opened, synchronize, reopened, closed]
+
+jobs:
+  breaking-changes:
+    if: github.event.action != 'closed'
+    # ... as above
+
+  code-to-docs:
+    if: github.event.action == 'closed' && github.event.pull_request.merged == true
+    # ...
+```
+
+## Configuration
+
+| Input | Required | Default | Description |
+| --- | --- | --- | --- |
+| `agent` | Yes | | Set to `breaking-changes` to run this workflow. |
+| `catalog-repo` | Yes | | Your catalog repository, in `owner/repo` format. |
+| `catalog-ref` | No | `main` | The catalog branch to read. |
+| `catalog-token` | No | `github.token` | A token that can read the catalog repository. |
+| `catalog-url` | No | | The URL of your hosted catalog. The comment links consumers and owners to it. |
+| `model` | No | `anthropic/claude-sonnet-4-6` | The model the agent uses. See [models](#models). |
+| `schema-extensions` | No | `.json,.yml,.yaml,.avro,.avsc,.proto,.graphql,.gql` | The file extensions treated as message schemas. |
+| `ignore-paths` | No | Build and dependency folders | Comma-separated paths or glob patterns to leave out of the review. |
+
+To check message contracts in other files, such as TypeScript types, set `schema-extensions`. Your list replaces the defaults, so include every extension you want checked:
+
+```yaml
+with:
+  schema-extensions: .json,.yaml,.ts
+```
+
+Only add source code extensions for files that contain message contracts: every changed file with a listed extension is checked.
+
+## Models
+
+Use any model from [these providers](https://pi.dev/models). Set `model` to a provider and model name, and pass your provider's key as an environment variable on the step:
+
+| Provider | Model example | Environment variable |
+| --- | --- | --- |
+| Anthropic | `anthropic/claude-sonnet-4-6` | `ANTHROPIC_API_KEY` |
+| OpenAI | `openai/gpt-5.1` | `OPENAI_API_KEY` |
+| OpenRouter | `openrouter/anthropic/claude-sonnet-4.6` | `OPENROUTER_API_KEY` |
+
+To use models in your own AWS account, use an `amazon-bedrock/` model, such as `amazon-bedrock/eu.anthropic.claude-sonnet-4-6`, and give the job AWS credentials with [`aws-actions/configure-aws-credentials`](https://github.com/aws-actions/configure-aws-credentials).
+
+## Data and privacy
+
+- **It's read-only.** It only comments on pull requests, and never edits your catalog.
+- **Your code goes to one place:** the model provider you configure. The agent runs in your GitHub Actions runner. EventCatalog never receives your code, your catalog or your pull requests.
+
+Each run sends one anonymous usage event: the outcome and the kind of error if it failed, the model, the run's duration, whether the pull request was open or merged, and the repository name. It never contains code, file names, paths, diffs or pull request content. To turn it off, set `POSTHOG_KEY: ''` in the step's `env`.
+
+## Versions
+
+Use `event-catalog/agents@v2` for the latest v2 release, or an exact release such as `event-catalog/agents@v2.1.0`, which never changes. Releases are listed on [GitHub](https://github.com/event-catalog/agents/tags).

package/dist/docs/development/ask-your-architecture/08-check-code-against-adrs.md

@@ -0,0 +1,169 @@
+---
+sidebar_position: 8
+keywords:
+  - ADR Compliance
+  - EventCatalog Agents
+  - architecture decision records
+  - ADR governance
+  - GitHub Actions
+sidebar_label: Check code against ADRs
+title: Check code against ADRs
+description: The ADR Compliance workflow comments on pull requests when the code conflicts with an architecture decision documented in your EventCatalog, citing the line and the decision.
+slug: /development/agents/set-up-adr-compliance
+---
+
+import { AdrComplianceComment } from '@site/src/components/AgentOutputs';
+import { AgentPrompt } from '@site/src/components/AgentPrompt';
+
+The **ADR Compliance** workflow checks the code changed in a pull request against the [architecture decision records](/docs/development/guides/resources/adrs/introduction) in your catalog. You choose which ADRs apply to the repository. If the code clearly conflicts with one, it comments with the line, the decision, and how to fix it. It never edits your catalog or blocks a merge.
+
+<AgentPrompt variant="adr-compliance" />
+
+### Example 
+<AdrComplianceComment />
+
+## How it works
+
+1. **Selects the ADRs.** It finds the ADRs matching your `adrs` input, and keeps the `accepted` ones at their latest version. If an accepted ADR amends one of them, it's included too, because the decision can't be judged correctly without it.
+2. **Finds the relevant ones.** It compares the ADR summaries with the changes, so only ADRs on the same topic are reviewed in full.
+3. **Reviews the changed lines.** It reports only clear conflicts. Code that follows an ADR, code the pull request didn't change, and comments that merely mention something an ADR rules out are not conflicts. A decision for a domain or system takes precedence over a broader one on the same topic.
+4. **Checks its citations.** The line must be one the pull request changed, and the quoted sentence must be in the ADR. A conflict that fails this check is dropped.
+5. **Comments on the pull request** with each conflict. The comment updates on every push, and says so once the conflicts are gone.
+
+If there are no conflicts, it doesn't comment.
+
+## Before you start
+
+You need:
+
+- An EventCatalog in a GitHub repository (the **catalog repository**), with the catalog at the root of the repository, and your decisions documented as [ADRs](/docs/development/guides/resources/adrs/creating-adrs).
+- A repository with the code you want to check (the **source repository**).
+- An API key for an AI model provider.
+
+## Setup
+
+In your source repository, add two secrets under **Settings → Secrets and variables → Actions**:
+
+- `ANTHROPIC_API_KEY`, or the key for [your model provider](#models).
+- `EVENTCATALOG_TOKEN`, a GitHub token that can read your catalog repository. The workflow never writes to it.
+
+Then add the workflow. It runs while the pull request is open, so a conflict is raised while the code can still change:
+
+```yaml title=".github/workflows/eventcatalog-adr-compliance.yml"
+on:
+  pull_request:
+    types: [opened, synchronize, reopened]
+
+jobs:
+  adr-compliance:
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+      issues: write
+      pull-requests: write
+    steps:
+      - uses: actions/checkout@v6
+        with:
+          ref: ${{ github.event.pull_request.head.sha }}
+          fetch-depth: 0
+      - uses: event-catalog/agents@v2
+        env:
+          # The key for your model's provider. This one is for the default model.
+          # Using another provider? Swap this variable and set `model` below.
+          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
+        with:
+          # The agent workflow to run.
+          agent: adr-compliance
+          # The ADRs to check against, as globs from your catalog's root.
+          # Here: the top-level adrs folder and the Orders domain.
+          adrs: adrs/**, domains/Orders/**
+          # Your catalog repository, in owner/repo format.
+          catalog-repo: your-org/your-catalog
+          # A token that can read your catalog repository.
+          catalog-token: ${{ secrets.EVENTCATALOG_TOKEN }}
+          # Optional: the model to use. Defaults to anthropic/claude-sonnet-4-6.
+          # model: openai/gpt-5.1
+```
+
+Replace `your-org/your-catalog` with your catalog repository, and set `adrs` to the [ADRs that apply to this repository](#choose-which-adrs-to-check). Keep `fetch-depth: 0`: the agent needs it to compare the pull request with its base branch.
+
+To check it works, open a pull request that does something one of your accepted ADRs rules out.
+
+## Choose which ADRs to check
+
+The `adrs` input is required. It takes comma-separated globs, relative to the root of your catalog. ADRs can live in any `adrs` folder in your catalog, so point the globs at wherever yours are:
+
+| To check against | Use |
+| --- | --- |
+| ADRs in the top-level `adrs` folder | `adrs/**` |
+| A domain, and everything nested in it | `domains/Orders/**` |
+| One system | `domains/Orders/systems/checkout-system/**` |
+| One service | `domains/Orders/services/OrdersAPI/**` |
+| ADRs that share a naming convention | `adrs/adr-orders-*/**` |
+| One ADR | `adrs/adr-012-use-outbox` |
+| Every ADR in the catalog | `'**/adrs/**'` |
+
+A typical repository checks against your organization-wide ADRs and those of its own domain:
+
+```yaml
+with:
+  adrs: adrs/**, domains/Orders/**
+```
+
+Globs start at the catalog root, so `adrs/**` means only the top-level folder, not every folder called `adrs`. A value that starts with `*` needs quotes in YAML.
+
+If `adrs` is missing or matches no ADRs, the run fails with an error that shows where your ADRs are, so a typo can't look like a clean pass.
+
+:::tip
+Checking every ADR in the catalog can raise conflicts with decisions meant for other teams. Start with the ADRs that apply to the repository.
+:::
+
+## Record an exception
+
+If a conflict is intentional, add a line to the pull request description with the ADR's `id` and your reason:
+
+```text
+adr-exception: adr-003-offload-async-work-to-worker small thumbnails only
+```
+
+The conflict then moves to an exceptions list in the comment, so reviewers can still see it. The agent reads the description when it runs, so push a commit or re-run the workflow after adding the line. To re-run automatically when the description changes, add `edited` to the `types`.
+
+A reason is required: a line without one is ignored. Exceptions are visible rather than enforced, so anyone who can edit the description can add one.
+
+If the decision itself has changed, propose a new ADR in your catalog instead. See [ADR relationships](/docs/development/guides/resources/adrs/relationships).
+
+## Configuration
+
+| Input | Required | Default | Description |
+| --- | --- | --- | --- |
+| `agent` | Yes | | Set to `adr-compliance` to run this workflow. |
+| `adrs` | Yes | | Comma-separated globs, relative to the catalog root, selecting the ADRs to check against. |
+| `catalog-repo` | Yes | | Your catalog repository, in `owner/repo` format. |
+| `catalog-ref` | No | `main` | The catalog branch to read. |
+| `catalog-token` | No | `github.token` | A token that can read the catalog repository. |
+| `catalog-url` | No | | The URL of your hosted catalog. The comment links ADRs to it. Without it, they link to your catalog repository. |
+| `model` | No | `anthropic/claude-sonnet-4-6` | The model the agent uses. See [models](#models). |
+| `ignore-paths` | No | Build and dependency folders | Comma-separated paths or glob patterns to leave out of the review. |
+
+## Models
+
+Use any model from [these providers](https://pi.dev/models). Set `model` to a provider and model name, and pass your provider's key as an environment variable on the step:
+
+| Provider | Model example | Environment variable |
+| --- | --- | --- |
+| Anthropic | `anthropic/claude-sonnet-4-6` | `ANTHROPIC_API_KEY` |
+| OpenAI | `openai/gpt-5.1` | `OPENAI_API_KEY` |
+| OpenRouter | `openrouter/anthropic/claude-sonnet-4.6` | `OPENROUTER_API_KEY` |
+
+To use models in your own AWS account, use an `amazon-bedrock/` model, such as `amazon-bedrock/eu.anthropic.claude-sonnet-4-6`, and give the job AWS credentials with [`aws-actions/configure-aws-credentials`](https://github.com/aws-actions/configure-aws-credentials).
+
+## Data and privacy
+
+- **It's read-only.** It only comments on pull requests, and never edits your catalog.
+- **Your code goes to one place:** the model provider you configure. The agent runs in your GitHub Actions runner. EventCatalog never receives your code, your catalog or your pull requests.
+
+Each run sends one anonymous usage event: the outcome and the kind of error if it failed, the model, the run's duration, whether the pull request was open or merged, and the repository name. It never contains code, file names, paths, diffs or pull request content. To turn it off, set `POSTHOG_KEY: ''` in the step's `env`.
+
+## Versions
+
+ADR Compliance needs `event-catalog/agents@v2.2.0` or later. Use `event-catalog/agents@v2` for the latest v2 release, or an exact release such as `event-catalog/agents@v2.2.0`, which never changes. Releases are listed on [GitHub](https://github.com/event-catalog/agents/tags).

package/dist/docs/development/components/custom-components/02-create-your-first-component.md

@@ -5,8 +5,12 @@ title: Create your first component
 description: Create a small reusable component and render it in a catalog page.
 ---
 
+import { AgentPrompt } from '@site/src/components/AgentPrompt';
+
 In this guide, we will create a simple component and add it to a service page.
 
+<AgentPrompt variant="custom-component" />
+
 ## Create the component
 
 Create a new file in your catalog.

package/dist/docs/development/customization/customize-visualizer/00-visualizer-nodes.md

@@ -30,8 +30,8 @@ name: Notification Service
 summary: |
   Service that handles orders
 styles:
-  icon: "BellIcon"
-  node: 
+  icon: /icons/bell.svg
+  node:
     color: purple
     label: "Custom"
 ---
@@ -45,6 +45,8 @@ styles:
 
 | ID | Required | Default | Description |
 | --- | --- | --- | --- |
-| `styles.icon` | No | Depends on resource type | The icon to use for the resource. Icons are from [hero icons](https://heroicons.com/). <br/> You can find a list of icons [here](https://unpkg.com/browse/@heroicons/react@2.1.5/24/outline/). |
-| `styles.node.color` | No | Depends on resource type | The color to use for the node. These are tailwind colors and you can find a list of them [here](https://tailwindcss.com/docs/colors). |
-| `styles.node.label` | No | Depends on resource type | The label to use for the node (side label). |
+| `styles.icon` | No | Depends on resource type | An icon shown next to the resource's name: a path to an image in your catalog's `public` folder (e.g. `/icons/bell.svg`) or an image URL. Domain, flow and entity nodes also take a [Heroicons](https://heroicons.com/) name (e.g. `BellIcon`). |
+| `styles.node.color` | No | Depends on resource type | The color to use for the node: a [Tailwind color](https://tailwindcss.com/docs/colors) name (e.g. `blue`, `emerald`) or a hex color (e.g. `#0ea5e9`). It colors the node's border, badge and handles. |
+| `styles.node.label` | No | Depends on resource type | The label shown in the node's type badge, in place of its type (e.g. `Service`). |
+
+Colors and labels apply to services, events, commands, queries, channels, data stores, data products, agents and flows.

package/dist/docs/development/developer-tools/api-catalog.md

@@ -109,4 +109,4 @@ When the EventCatalog MCP server is enabled, an additional entry pointing at `/d
 
 Only services and domains are included in v1 of this endpoint. Events, commands, queries, data products, schemas, diagrams, teams, and users are out of scope for this release.
 
-For a broader machine-readable index of your catalog content, see [llms.txt](/docs/development/ask-your-architecture/llms.txt) and [schemas.txt](/docs/development/ask-your-architecture/schemas.txt).
+For a broader machine-readable index of your catalog content, see [llms.txt](/docs/development/developer-tools/llms.txt) and [schemas.txt](/docs/development/developer-tools/schemas.txt).

package/dist/docs/development/{ask-your-architecture/02-llms.txt.md → developer-tools/llms.txt.md}

@@ -52,6 +52,8 @@ The recommended URLs for AI tools are at the catalog root:
  - `https://<your-catalog-url>/llms-full.txt`
     - Demo: https://demo.eventcatalog.dev/llms-full.txt
 
+The ubiquitous language of your catalog is also available as [ubiquitous-language.txt](/docs/development/developer-tools/ubiquitous-language.txt).
+
 The legacy paths `/docs/llm/llms.txt` and `/docs/llm/llms-full.txt` still work for backward compatibility.
 
 ### How to use LLMS.txt?

package/dist/docs/development/{ask-your-architecture/03-schemas.txt.md → developer-tools/schemas.txt.md}

@@ -17,7 +17,7 @@ Message schemas and service specifications can be fetched from your EventCatalog
 
 ### What is schemas.txt?
 
-Schemas.txt is very similar to [LLMS.txt](/docs/development/ask-your-architecture/llms.txt), but it is specifically for schemas in your EventCatalog. 
+Schemas.txt is very similar to [LLMS.txt](/docs/development/developer-tools/llms.txt), but it is specifically for schemas in your EventCatalog. 
 
 Schemas.txt supports any schema format for your messages (e.g Avro, Protobuf, JSON Schema etc) and any specification for your services (e.g OpenAPI, AsyncAPI, GraphQL etc).
 

package/dist/docs/development/developer-tools/ubiquitous-language.txt.md

@@ -0,0 +1,42 @@
+---
+sidebar_position: 8
+keywords:
+- ubiquitous language
+- glossary
+- AI
+- LLM
+sidebar_label: ubiquitous-language.txt
+title: ubiquitous-language.txt
+description: Give AI tools the ubiquitous language of your organization
+---
+
+import AddedIn from '@site/src/components/MDX/AddedIn';
+
+<AddedIn version="5.9.0" />
+
+Give AI tools one file with the ubiquitous language of your whole organization.
+
+### What is ubiquitous-language.txt?
+
+The file lists the terms of every domain and subdomain, with subdomains under their parent domain. It is generated from your [`ubiquitous-language.mdx`](/docs/development/guides/domains/ownership-and-language/adding-ubiquitous-language) files, so there is nothing to configure.
+
+Terms are never merged, because a word can mean different things in different domains. Terms defined in more than one domain are listed together at the top of the file, with the meaning in each domain.
+
+```txt
+## Terms defined in more than one domain
+- Reservation
+  - Fulfilment: A temporary hold on stock for a specific order, taken during checkout.
+  - Ordering: A temporary hold on stock for the items in a cart, taken during checkout.
+```
+
+Each term is one line with its summary (or its description, flattened to one line, when it has no summary). Each domain section links to that domain's `/docs/domains/{id}/language.mdx` for the full definitions.
+
+### Access the file
+
+ - `https://<your-catalog-url>/docs/llm/ubiquitous-language.txt`
+
+The file is turned on and off with the `llmsTxt` setting, the same as [llms.txt](/docs/development/developer-tools/llms.txt). When it is disabled the file returns a 404. It is linked from the LLM access settings page, and from the Ubiquitous Language section of `llms.txt`.
+
+### Use with the MCP server
+
+The [EventCatalog MCP server](/docs/development/ask-your-architecture/mcp-server/getting-started#available-tools) exposes the same language through the `explainUbiquitousLanguageTerms` tool.

package/dist/docs/development/guides/domains/03-ownership-and-language/02-adding-ubiquitous-language.md

@@ -96,5 +96,8 @@ When you add a ubiquitous language dictionary to your domain, it will automatica
 
 Clicking on a term in the Domain Language explorer will open that term in a new page. 
 
+### Share with AI tools
 
+<AddedIn version="5.9.0" />
 
+Your terms from every domain are also available to AI tools in one file, [ubiquitous-language.txt](/docs/development/developer-tools/ubiquitous-language.txt), and through the `explainUbiquitousLanguageTerms` tool of the [MCP server](/docs/development/ask-your-architecture/mcp-server/getting-started#explain-ubiquitous-language).

package/dist/docs/development/guides/resources/adrs/01-introduction.md

@@ -20,6 +20,7 @@ Documenting ADRs in your catalog gives your team:
 - **Context** — anyone can see what alternatives were considered and why a particular path was chosen.
 - **Traceability** — decisions are linked directly to the services, events, domains, and flows they affect via `appliesTo`.
 - **Lifecycle tracking** — each ADR has a status (`proposed`, `accepted`, `rejected`, `deprecated`, `superseded`) so it is clear which decisions are still in force.
+- **Checks in pull requests** — the [ADR Compliance workflow](/docs/development/agents/set-up-adr-compliance) comments when a pull request's code conflicts with an accepted decision.
 - **AI-ready context** — because ADRs sit alongside the resources they govern, the [EventCatalog MCP server](/docs/development/ask-your-architecture/mcp-server/introduction) can surface the *why* behind your architecture to AI assistants, not just the *what*. When an LLM is reasoning about a service or event, it picks up the decisions, trade-offs, and constraints recorded in your ADRs.
 
 ## Lifecycle statuses

package/dist/eventcatalog.cjs

@@ -33,11 +33,12 @@ var import_node_path22 = require("path");
 var import_node_http = __toESM(require("http"), 1);
 var import_fs = __toESM(require("fs"), 1);
 var import_node_path23 = __toESM(require("path"), 1);
-var import_node_url2 = require("url");
+var import_node_url3 = require("url");
 var import_node_module3 = require("module");
 
 // src/generate.js
 var import_node_path3 = __toESM(require("path"), 1);
+var import_node_url2 = require("url");
 
 // src/eventcatalog-config-file-utils.js
 var import_promises2 = require("fs/promises");
@@ -174,7 +175,7 @@ var verifyRequiredFieldsAreInCatalogConfigFile = async (projectDirectory) => {
 var import_picocolors = __toESM(require("picocolors"), 1);
 
 // package.json
-var version = "5.8.0";
+var version = "5.9.1";
 
 // src/constants.ts
 var VERSION = version;
@@ -273,7 +274,7 @@ var generate = async (PROJECT_DIRECTORY) => {
         plugin = plugin.replace("<rootDir>", PROJECT_DIRECTORY);
       }
       try {
-        const importedGenerator = await import(plugin);
+        const importedGenerator = await (import_node_path3.default.isAbsolute(plugin) ? import((0, import_node_url2.pathToFileURL)(plugin).href) : import(plugin));
         const generator2 = getDefaultExport(importedGenerator);
         await generator2({ eventCatalogConfig: {} }, pluginConfig);
       } catch (error) {
@@ -3090,7 +3091,7 @@ Run npm i @eventcatalog/core to update`;
 };
 
 // src/eventcatalog.ts
-var currentDir = import_node_path23.default.dirname((0, import_node_url2.fileURLToPath)(importMetaUrl));
+var currentDir = import_node_path23.default.dirname((0, import_node_url3.fileURLToPath)(importMetaUrl));
 var astroCli = import_node_path23.default.join(import_node_path23.default.dirname((0, import_node_module3.createRequire)(importMetaUrl).resolve("astro/package.json")), "bin/astro.mjs");
 var ASTRO_IN_FOREGROUND = { ASTRO_DEV_BACKGROUND: "1", ASTRO_PREVIEW_BACKGROUND: "1" };
 var program = new import_commander.Command().version(VERSION);
@@ -3576,7 +3577,7 @@ var startServerCatalog = async () => {
   const base = (config?.base || "/").replace(/\/$/, "");
   await runCommandWithFilteredOutput({
     command: process.execPath,
-    args: ["--input-type=module", "-e", SERVER_BOOTSTRAP, (0, import_node_url2.pathToFileURL)(serverEntryPath).href],
+    args: ["--input-type=module", "-e", SERVER_BOOTSTRAP, (0, import_node_url3.pathToFileURL)(serverEntryPath).href],
     cwd: dir,
     env: {
       PROJECT_DIR: dir,

package/dist/eventcatalog.js

@@ -1,18 +1,18 @@
-import {
-  stopChildWithParent
-} from "./chunk-S5GWAUG5.js";
 import {
   runMigrations
 } from "./chunk-XUAF2H54.js";
 import "./chunk-CA4U2JP7.js";
+import {
+  stopChildWithParent
+} from "./chunk-S5GWAUG5.js";
 import {
   log_build_default
-} from "./chunk-E636DOFG.js";
+} from "./chunk-3PWCUWQC.js";
 import {
   getLicenseStatus,
   printLicenseStatus
 } from "./chunk-AD7CL772.js";
-import "./chunk-Z6UUCTIB.js";
+import "./chunk-YBM7MCOY.js";
 import "./chunk-YRZK7HKX.js";
 import "./chunk-CA6WCQ2T.js";
 import "./chunk-CPW6G62V.js";
@@ -39,10 +39,10 @@ import {
 } from "./chunk-NKNOXQ62.js";
 import {
   generate
-} from "./chunk-DT63JMNP.js";
+} from "./chunk-A3256YCN.js";
 import {
   logger
-} from "./chunk-WLXXZTLD.js";
+} from "./chunk-JDSFD7IC.js";
 import {
   resolve_catalog_dependencies_default
 } from "./chunk-PD7KTSYN.js";
@@ -79,7 +79,7 @@ import {
 } from "./chunk-LFQJXLHG.js";
 import {
   VERSION
-} from "./chunk-YU6FEGOK.js";
+} from "./chunk-KGFAIGOT.js";
 import {
   getEventCatalogConfigFile,
   verifyRequiredFieldsAreInCatalogConfigFile

package/dist/generate.cjs

@@ -34,6 +34,7 @@ __export(generate_exports, {
 });
 module.exports = __toCommonJS(generate_exports);
 var import_node_path3 = __toESM(require("path"), 1);
+var import_node_url2 = require("url");
 
 // src/eventcatalog-config-file-utils.js
 var import_promises2 = require("fs/promises");
@@ -105,7 +106,7 @@ var getEventCatalogConfigFile = async (projectDirectory) => {
 var import_picocolors = __toESM(require("picocolors"), 1);
 
 // package.json
-var version = "5.8.0";
+var version = "5.9.1";
 
 // src/constants.ts
 var VERSION = version;
@@ -204,7 +205,7 @@ var generate = async (PROJECT_DIRECTORY) => {
         plugin = plugin.replace("<rootDir>", PROJECT_DIRECTORY);
       }
       try {
-        const importedGenerator = await import(plugin);
+        const importedGenerator = await (import_node_path3.default.isAbsolute(plugin) ? import((0, import_node_url2.pathToFileURL)(plugin).href) : import(plugin));
         const generator2 = getDefaultExport(importedGenerator);
         await generator2({ eventCatalogConfig: {} }, pluginConfig);
       } catch (error) {

package/dist/generate.js

@@ -1,8 +1,8 @@
 import {
   generate
-} from "./chunk-DT63JMNP.js";
-import "./chunk-WLXXZTLD.js";
-import "./chunk-YU6FEGOK.js";
+} from "./chunk-A3256YCN.js";
+import "./chunk-JDSFD7IC.js";
+import "./chunk-KGFAIGOT.js";
 import "./chunk-4G7FSRPN.js";
 export {
   generate

package/dist/utils/cli-logger.cjs

@@ -36,7 +36,7 @@ module.exports = __toCommonJS(cli_logger_exports);
 var import_picocolors = __toESM(require("picocolors"), 1);
 
 // package.json
-var version = "5.8.0";
+var version = "5.9.1";
 
 // src/constants.ts
 var VERSION = version;

package/dist/utils/cli-logger.js

@@ -1,7 +1,7 @@
 import {
   logger
-} from "../chunk-WLXXZTLD.js";
-import "../chunk-YU6FEGOK.js";
+} from "../chunk-JDSFD7IC.js";
+import "../chunk-KGFAIGOT.js";
 export {
   logger
 };