Bedrock "mods" are a zip with a JSON manifest, not a jar — a short writeup of what that changes (Bedrock, not Java)

Bedrock only again, so skip if you're Java — but the packaging difference is genuinely interesting if you've only ever shipped a jar, and it's why tooling on the two sides looks so different.

A Bedrock add-on isn't compiled. It's a zip containing manifest.json plus folders of JSON and (optionally) JavaScript. The manifest declares:

• A UUID per pack, and a UUID per module inside it
• min_engine_version, an array like [1, 21, 0]
• Modules with types: data (behaviour), resources, script, world_template, skin_pack
• For script modules, a dependency on @minecraft/server with a version, which is how you know which Script API generation it targets
• Dependencies on other packs, referenced by their UUID rather than by name

Two consequences that surprised me building tooling around it.

Because dependencies are UUIDs, you can resolve a pack's dependency graph without executing anything or trusting a name string — just match the declared UUIDs against packs you already know about. I use that to auto-link listings to each other. No equivalent to Maven coordinates, and none needed.

And because the type is declared, you can classify a pack accurately from the manifest and folder layout alone. A skin_pack module is unambiguous. A behaviour+resource pair is an add-on. A resource-only pack with a ui/ folder is a UI pack. No heuristics on filenames.

The flip side is there's no compilation step to catch anything, so a malformed manifest just fails silently in-game, and version compatibility is whatever the author typed.

I've been building a marketplace around this parsing (link below) but the packaging details above are just how Bedrock works — useful whether or not you ever touch my site. Happy to go deeper on the Script API versioning if anyone's curious, it's the messiest part.

https://bedrockbazaar.com

Not affiliated with Mojang or Microsoft.