Skip to main content

server

Get two Minecraft addons talking to each other.

Beta

@bedrock-core/server is in beta: the API can change between releases. Pin exact versions and read the changelog before upgrading.

What is @bedrock-core/server?​

Every behavior pack runs its scripts in its own isolated realm. Two packs in the same world cannot import each other, share a module, or see each other's variables.

@bedrock-core/server builds a framework on top of the one thing that does cross a realm boundary: script events. Addons discover each other at runtime, call each other, share state, and expose their settings and guides through one common surface.

world
 ├─ drav0011_economy    serves getBalance over RPC, publishes its config schema
 ├─ drav0011_shop       depends on economy, calls it, publishes its own schema
 └─ someone_leaderboard shop's optional feature lights up because it is present

None of them imported each other. They found each other at runtime.

Install one package​

npm install @bedrock-core/server

That is the answer for an addon. It is a meta package that pins a matching set of the stack and re-exports everything, so import { core } from '@bedrock-core/server' is all you need. Each package underneath stays reachable at its own subpath — /sync, /db, /observable — for when you reach past core to the thing itself.

The packages underneath are strictly layered and installable on their own if you are building a framework layer of your own: @bedrock-core/server-runtime (registry, features, shared, events, db, translations, slots), @bedrock-core/sync (bus, discovery, RPC, the mirror, events), @bedrock-core/db (persisted documents) and @bedrock-core/observable (the reactive primitive every accessor is).

What you get​

  • Registry — declare creator + pack once and every other bedrock-core addon sees you, with version, dependencies and display labels. Missing soft dependencies log and fire an event; they never block loading.
  • RPC — typed request/response calls to another addon, with a timeout so an absent peer can never hang your code, and one rule a handler applies on behalf of a player.
  • Shared — a flat shape every realm mirrors locally, one observable per key. Reads are synchronous; writes broadcast a delta; only the owner writes.
  • Events — a broadcast delivered and forgotten, typed by its payload, so a peer hears that something happened without polling for it.
  • Db — persisted documents keyed by target, on whatever dynamic properties the target itself can hold, with versions and lazy migrations. Local: a peer reaches one only through a method you wrote.
  • Features — behavior that auto-enables when a condition over the registry becomes true, and auto-disables when it stops being true.
  • Translations — announce your i18n bundle so any addon's UI can resolve and measure your strings. Your screens and your list page are announced by @bedrock-core/navigation.
  • Host election — a deterministic rule for "which realm does the work only one realm may do".

Next steps​

  • Installation — scaffold with the CLI, or install and register by hand
  • Sharing data between addons — which of shared, events and RPC carries what, and what stays local
  • Trust model — what the framework defends against, and what it cannot
  • core — the runtime reference: register(), declarations, slots, registry, features, shared, events, db
  • sync — the transport reference: nodes, discovery, RPC, the mirror, events
On this page