Context

As explained in our 2025 roadmap blog post:

In mxGraph, everything was public, leading to frequent breaking changes with each improvement. 🔄 The goal is to clearly define what belongs in the public API and what is meant for extensions. This will help limit breaking changes and provide a more stable experience for users.

This issue tracks the effort to define and document the public API surface of maxGraph.

Why this matters

Due to its ES5 legacy, maxGraph still exposes many internals:

• Public fields that should be private.
• Redundant getters/setters.
• Utility methods that are no longer needed.

This makes it hard for users to know what is safe to rely on, and for us to make improvements without unintentionally introducing breaking changes.

Clarifying the boundaries will help:

• Improve API documentation.
• Make maxGraph easier to maintain.
• Allow for tree shaking and bundling improvements.
• Provide a clearer path for contributors and extension authors.

Scope and possible actions

This includes:

• Auditing exported members from all packages/modules.
• Identifying what is officially part of the public API and what is internal-only.
• Tagging internal elements with @internal, @deprecated, or @experimental where appropriate.
• Making internal-only items private: this doesn’t necessarily mean using JavaScript #private fields (though it can), but rather not exposing them in TypeScript types, not exporting them from modules, or making them inaccessible from standard usage.
• Removing or deprecating APIs that are redundant or no longer useful (especially those inherited from mxGraph/ES5).
• Moving internal utilities or types out of the public API surface.
• Defining what is safe to override or extend, and clearly documenting extension points.
• Writing down a “public API contract” that we can rely on to avoid accidental breakage.

Related work

This issue will link to sub-issues and PRs as work progresses.