Project and Packaging

minewright-project sets up and packages a Bedrock add-on: the behavior and resource pack folders, manifest.json with current versions and fresh UUIDs, a TypeScript build bundled with esbuild, the .mcaddon, and install steps for your platform. Its outcome: one command that builds the script bundle, one that packs the .mcaddon, and install steps for your device only.

Files: skills/minewright-project/SKILL.md and references/versions-and-formats.md (a dependency set that installs and lints together, and the component names that move with format_version). Tier fast: module and engine versions move with every game release, so the skill re-checks them every three days (Research and freshness).

Layout

my-addon/
  behavior_pack/        manifest.json, entities/, items/, scripts/main.js (built), texts/
  resource_pack/        manifest.json, entity/, models/entity/, textures/, render_controllers/, texts/
  src/                  TypeScript sources (main.ts, config.ts, core/*.ts)
  test/                 node --test unit tests for src/core (*.test.ts)
  package.json  tsconfig.json  eslint.config.mjs  scripts/pack.py (or pack.mjs)

One namespace, lowercase letters, digits and underscores: given_jar, not given.jar.

Manifests

The numbers below were checked on 2026-10-27. The skill re-checks them before use.

• format_version 2; every UUID new and used once (a shared UUID can stop a pack loading).
• min_engine_version [1, 26, 50], what Mojang's own samples use. Never above the oldest game version your players have.
• Script modules by plain version string: @minecraft/server 2.11.0 and @minecraft/server-ui 2.3.0.
• The resource pack depends on the behavior pack's header UUID (and the other way round), so they travel together.
• Bump header.version on every release you hand out, or a device may keep its cached copy.

Bedrock Dedicated Server 1.26.60.6 lists the module versions it accepts when asked for one it lacks: @minecraft/server 0.1.0, 1.19.0, 2.11.0, 2.12.0-beta and 3.0.0-alpha, and @minecraft/server-ui 0.1.0, 1.3.0, 2.3.0, 2.4.0-beta and 3.0.0-alpha.

Component names move with format_version

A behavior-pack entity is parsed against the schema of its format_version. From 1.26.10 the schema no longer knows minecraft:pushable: use minecraft:pushable_by_entity: {} and minecraft:pushable_by_block: {}, or neither. Bedrock Dedicated Server then refuses the whole entity, and the game shows no error at all. mw_check.py's components check catches it (Static checks). Creator Tools 0.20.0 recommends raising entity versions to 1.26.50 without flagging the components the raise breaks, so after any raise the skill reruns the checks and the server self-test.

Vanilla resource files still use old versions (client entities 1.10.0; render controllers, animations and geometry 1.8.0), so there is no need to raise those.

TypeScript build

The npm types must match the manifest. The newest TypeScript (7.x) and ESLint (10.x) break the Minecraft lint plugin, so the skill pins a set that installs and lints together:

Package	Pin	Why
@minecraft/server	2.11.0	equals the manifest's module version
@minecraft/vanilla-data	1.26.60	ids for the current game
typescript	5.9.3	typescript-eslint 8.72.1 allows only <6.1.0; eslint-plugin-minecraft-linting 2.0.13 depends on typescript ^5.6.0
eslint, @eslint/js	9.39.5	the Minecraft lint plugin depends on eslint ^9.17.0
typescript-eslint	8.72.1	flat config with type-aware rules
eslint-plugin-minecraft-linting	2.0.13	Script API rules from Mojang
esbuild	0.28.2	bundles src/main.ts; --external:@minecraft/* works
@types/node	24.19.2	node:test types for the unit tests

The build script from the skill (the example add-on uses the same line):

"build": "esbuild src/main.ts --bundle --format=esm --platform=neutral --target=es2022 --external:@minecraft/* --outfile=behavior_pack/scripts/main.js"

• @minecraft/* stay external: the game provides them. Everything else goes into one file.
• tsconfig.json: "module": "es2022", "moduleResolution": "bundler", "strict": true, "noEmit": true, and for Node 24's type stripping in tests "allowImportingTsExtensions": true, "erasableSyntaxOnly": true, "verbatimModuleSyntax": true and "types": ["node"]. No enum and no constructor parameter properties.
• npm 11 warns that esbuild's install script is not approved (allow-scripts). esbuild works without it through its platform package, so leave it unapproved. The example's npm ci printed that warning on 2026-10-27 and the build still ran.
• Mojang's @minecraft/core-build-tasks (5.7.1) with the ts-starter sample is the official alternative; pin exact versions instead of its caret ranges. Creator Tools' CLI (mct create, mct add, mct deploy; Node 22+) scaffolds projects too.

Package

An .mcaddon is a zip with one folder per pack at its root; a .mcpack is a zip of one pack. The example's scripts/pack.py names the folders given_jar_BP/ and given_jar_RP/, refuses to pack when a manifest version differs from package.json, and refuses when the script bundle is missing. Its output on the built example:

$ python scripts/pack.py
dist\given-jar-0.1.0.mcaddon: 19 files, 388 KB

Creator Tools warns above about 100 MB because phones and Realm uploads struggle.

Install

Per platform, on Platforms and install: the Windows GDK folder and the import bug, phones and tablets, consoles through a Realm, and LAN play.