v0.1.0

The first release of scripting-nodejs, and a pre-release: it runs behaviour packs on Node.js on both Linux and Windows servers, and the limitations below are ones you will meet rather than ones we expect you not to.

scripting-nodejs replaces the Bedrock Dedicated Server's built-in QuickJS script engine with a real Node.js runtime, so the behaviour packs you already run keep their @minecraft/* imports and gain the whole npm ecosystem behind them.

Install

1. Install Endstone v0.11 or newer and start your server once so the folder layout exists.
2. Download the archive for your platform below.
3. Unzip it over your server root — the archive is rooted there already, so everything lands in plugins/.
4. Restart the server.

There is nothing to configure, and your behaviour packs stay exactly as they are.

What works

• Behaviour-pack scripts run on Node.js instead of the built-in engine. Your packs keep their @minecraft/* imports and need no changes.
• import and import() of node: builtins, npm packages and files on disk, including worker threads and full ICU.
• A pack's dependencies are its own. A bare specifier resolves from the pack's own node_modules first, then the packs directory, then the server, so two packs can depend on different versions of the same package. A .mcpack behaves the same, except that nothing can read a node_modules that exists only inside a zip.
• npm and corepack ship with the plugin, and a pack's declared dependencies are installed before its scripts run — nothing has to be installed on the server.
• console.log, .info, .debug, .warn and .error reach the server log, formatted the way Node formats them, stack frames included.
• Errors read the way they do on the built-in engine — class, message and a pack-relative stack — matched against the real engine character for character by a behaviour pack that runs on both.
• Nothing a pack can read of its own files carries the server's path. import.meta.url and every frame naming a pack file is relative to the pack.
• Your script-watchdog settings still apply. A pack that stops returning is cut off at the hang threshold and the tick carries on; one that allocates without limit is terminated against the script-memory ceiling rather than taking the process down.
• Script timings and memory figures are real, so the Slow, Spike, Hang and high-memory thresholds you configure behave as they do on the built-in engine.
• Sourcemap support, when a pack was built with a bundler that leaves debug ids behind.

Known limitations

• No debugger and no profiler. You cannot attach a debugger to a pack, set a breakpoint, step, or take a CPU profile. Debugging is console.log and stack traces.
• Stack overflow is invisible to an operator. Runaway recursion reaches the log as a RangeError and raises no watchdog event.
• A stack frame from an npm package names the server's own directory. A pack's own frames carry nothing, but a package Node resolved for itself keeps the absolute path it was found at, so an error caught from a package and shown to a player can put your install path in front of them.
• Script code shares the server tick. Pack JavaScript that blocks stalls the server, as it does on the built-in engine.
• A few binding paths answer undefined. Container properties handed back by reference work in neither direction, and a native class the built-in engine makes for…of-iterable is not iterable here.
• A Bedrock update can drop you back to the built-in engine. The plugin finds where to install itself by byte pattern, and a server update breaks that, leaving one error line in the log until a new build ships — so check the log after updating BDS.

Compatibility

	Supported
Endstone	v0.11
Bedrock Dedicated Server	1.26.x
Platforms	Linux (x64), Windows (x64)

Windows has had far less real-server time than Linux, so Windows reports are especially useful.

Feedback

Bug reports and feature requests go in Issues; TROUBLESHOOTING says what makes a report actionable. Questions and show-and-tell go in Discussions or on Discord.

Full detail in the changelog.