feat: add registerDefaultStyleElements to register all builtin style elements - #1142

Problem

Two documentation pages already referred to a registerDefaultStyleElements function as the place to check which style elements maxGraph registers by default:

• packages/website/docs/usage/perimeters.md: "To check the list of registered perimeters, refer to the registerDefaultStyleElements function."
• packages/website/docs/usage/edge-styles.md: "To check the list of registered EdgeStyles, refer to the registerDefaultStyleElements function."

No such function existed. The four existing helpers (registerDefaultEdgeMarkers, registerDefaultEdgeStyles, registerDefaultPerimeters and registerDefaultShapes) had to be called one by one, and the only place listing them all was the private Graph.registerDefaults() override, which is not reachable from user code.

Solution

Add registerDefaultStyleElements(), which calls the four helpers. BaseGraph consumers who do want every builtin now get a single entry point without subclassing, and Graph.registerDefaults() delegates to it instead of duplicating the list, so there is a single source of truth.

import { BaseGraph, registerDefaultStyleElements } from '@maxgraph/core';

registerDefaultStyleElements();

const graph = new BaseGraph({ container });

The two documentation pages quoted above now point at something that exists.

Why a dedicated module

The function lives in packages/core/src/view/register-style-elements.ts rather than in view/style/register.ts. Adding an import of view/shape/register-shapes.js to the latter would create a static edge from a module that applications import for a single edge style helper (registerOrthogonalEdgeStyle, for instance) towards all sixteen builtin shapes. Bundlers drop it thanks to the side-effect-free package declaration, but the granularity of that analysis varies between bundlers, so the edge is better avoided entirely.

Tree-shaking caveat

Registering everything defeats tree-shaking, which is the whole point of BaseGraph. This is stated in the JSDoc and in a warning in the Global Configuration page, so the function does not read as the recommended default. It is meant as a convenience for prototyping, and as the first step of a Graph to BaseGraph migration: load everything so the application behaves as before, then trim progressively.

Changes

• packages/core/src/view/register-style-elements.ts: the new function
• packages/core/src/index.ts: export it
• packages/core/src/view/Graph.ts: registerDefaults() delegates to it
• packages/core/__tests__/view/register-style-elements.test.ts: 5 tests covering the four registries and idempotence
• packages/website/docs/usage/global-configuration.md: document it alongside the four granular functions, with the tree-shaking warning

No CHANGELOG.md entry: this is not a breaking change.

Related to #665.

Validation

• npm run build -w packages/core
• npm test -w packages/core: 540 tests, 61 suites
• npm run check:circular-dependencies -w packages/core
• npm run lint
• npm run build -w packages/website

Summary by CodeRabbit

• New Features

  • Added a public helper to register all default styling elements at once.
  • Default graph styling is now registered consistently through this helper.

• Documentation

  • Documented the new registration helper and its impact on bundle size, including guidance for preserving tree-shaking.

• Tests

  • Added coverage for default markers, styles, perimeters, shapes, and repeated registration behavior.