Mind Elixir Core: ten export subpaths, a bus of named operations, and no markdown by default

The container is one div with a height

Framework agnostic is not a slogan here, it is the integration contract. You create a container element, give it a height and a width, and pass it to the library.

<div id="map"></div>
<style>
  #map {
    height: 500px;
    width: 100%;
  }
</style>

The `el` option accepts either that selector or an actual element reference, so a component that already has a node can hand it over directly. The rest of the documented options are small and legible: a direction constant, a toolbar flag that defaults to on, a keypress flag that also defaults to on, an overflow behaviour flag defaulting to off, and a mouse selection button where zero is the left button and two is the right.

The context menu takes a locale plus feature flags for focus and link editing, and an extend array for your own entries. The locale list is eighteen values, from Chinese variants through English, Russian, Japanese, Portuguese, Italian, Spanish, French, Korean and a tail of European languages.

Nothing in that list requires a framework, which is why the playgrounds are published in vanilla JavaScript, React and Vue side by side.

Ten export subpaths, including a lite build and a layout helper

The package manifest's exports map is longer than most libraries of this size, and each entry answers a different question.

The default entry ships the library with its types. Then there is a lite build published as a separate subpath and emitted as an IIFE bundle, which is what you want when you are dropping the map into a page with a script tag and no module system. There is a layout utility exported from its own path whose filename says what it is for, a server side layout.

Three more entries are worth knowing. An i18n entry point means the translation strings are a separate chunk rather than something you have to tree shake out of the main bundle. A plaintext converter entry point does the reverse conversion. And an example entry point carries sample data with types, which is how the documentation imports a working map.

Then the small inconsistency: both `./style` and `./style.css` resolve to the same stylesheet. Two names, one file, which is friendly for people who type the shorter one and harmless for everyone else.

The map is generated, incidentally. There is a script whose only job is to generate the members list, which is why it never drifts out of sync with the build output.

Markdown is off, and the parser is yours to supply

The markdown section is the clearest statement of the project's philosophy in the whole documentation.

By default markdown processing is disabled. If you want it, you pass a function. The documented shape takes text and returns transformed text, and the examples show two ways: a hand written function that does its own replacements for bold, emphasis and code spans, or a wrapper around an existing library such as marked or markdown-it.

So the library does not bundle a parser, does not pick one for you, and does not have an opinion about which markdown dialect your notes use. If you already have a markdown pipeline in the project, you hand it the same function and get identical output everywhere.

That is a small decision with a large consequence for bundle size, which is consistent with the rest of the design: the lite build exists for the same reason, and the stylesheet is a separate entry point rather than something injected by JavaScript.

The bus reports operations by name, not by diff

Event handling is where a library like this earns its keep, because undo and redo, persistence and collaboration all hang off it.

There is a bus on the instance, and the documented listener for edits is called `operation`. The payload carries a `name` that is one of a fixed set: inserting a sibling, adding a child, removing a node, beginning an edit and finishing an edit. Moving a node is a separate case, because it carries two objects, a `from` and a `to`, rather than one target.

That distinction is the useful part. A move is not a removal plus an addition as far as the consumer is concerned, so an undo implementation or a change log does not have to reconstruct intent from a pair of events.

Two more listeners are documented alongside it: one for selected nodes, which receives the selection, and one for a node being expanded.

The names double as the operation vocabulary. Anything you build on top, including the built in undo and redo that the feature list claims, is expressed in the same terms.

Data is a plain object: get it, stringify it, init it, refresh it

Data handling is four methods and one shape, which is exactly what you want from a library that has to coexist with your own state management.

Export is a call that returns the node data object, plus a variant that stringifies it. Import is split in two on purpose: initialisation takes the data once when the instance is set up, and refresh takes new data to update an existing instance. Keeping those separate means you do not have to destroy and rebuild the map to apply a change.

The node shape is documented field by field. A node has a topic, an id, a style object with font size, colour and background, an expanded flag, a parent reference, tags, icons, a hyperlink, and an image object. Inside the image object the URL and the height are marked required, with a comment explaining why: the height and width have to be queried and calculated so the image displays at the right size.

The sample id in the documentation is a sixteen character hex style string, which is a hint that ids are generated rather than sequential, and therefore safe to use as keys in your own store.

Eight translated readmes and eighteen menu locales

The documentation surface is unusually wide for a library, and it is worth naming because it tells you who is using it.

The top of the README links eight language versions of itself: English, Chinese, Spanish, French, Portuguese, Russian, Japanese and Korean. Each is a separate file in a readme directory rather than a machine translation served from one page.

Separately, the context menu locale option accepts eighteen values. Those are not the same list. The readmes cover the languages the documentation was translated into, and the locale values cover what the interface itself can be rendered in, which adds Italian, Romanian, Danish, Finnish, German, Dutch, Norwegian and Swedish among others.

The translations come with a separate stylesheet in the tree, which is the practical detail: bundling a flag icon font and a font family for every language would defeat the point of a lightweight core, so both are importable only if you want them.

If you are adding a language, the path of least resistance is the locale list in the options rather than anything structural.

Playwright, Biome, API Extractor and a beta publish path

The tooling is conventional and modern, which makes it easy to guess what any script does before reading it.

Lint and format are both handled by one tool over the source directory, with warnings promoted to errors for linting. Development and preview run through Vite. The build is a JavaScript build step followed by a TypeScript compile, and the tests are Playwright, with a headed mode for watching them and a coverage flow that cleans old output, runs the suite, produces a report and serves the result locally.

Documentation of the API surface is generated rather than written: an API Extractor run produces a report, and a second step turns that report into markdown. There is also a KaTeX stylesheet at the root, which is how mathematical notation is rendered in a node rather than left to the consumer.

Commits are linted through commitlint with a Husky hook, which explains the tidy release history.

And there are two publish paths. The ordinary one builds and publishes, while a separate beta script builds and publishes under the beta tag. The release list shows that path in use: a beta build in late July, then the stable version two days later, then a patch a fortnight after that.

Editorial conclusion

Use Mind Elixir if you want a mind map in an existing application and would rather bind it to a DOM element than adopt a framework's component model, since the only integration point is an element plus an options object. It gives you drag and drop editing, multi-node operations, undo and redo, and SVG, PNG and HTML export without much surface area. Skip it if you need server-side rendering of the map itself, since that is a separate export rather than the default path, and skip it if you expect a bundled markdown renderer, because the parser is disabled until you pass one. Before you upgrade from an earlier major version, read the version five breaking changes page, pin an exact version while you do, and check which of the subpaths you actually use, since both style entry points resolve to the same stylesheet.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. SSShooter/mind-elixir-core on GitHub