Contributing

Contributing

1. Discuss first. Open an issue or discussion before large features or architecture changes.
2. Keep the core edition-neutral. Code in core/ must never import java/ or bedrock/.
3. No edition-specific IDs in the core. Never store Java state IDs or Bedrock runtime IDs in core/ types — resolve them only at the adapter boundary.
4. Verify before submitting:

   go fmt ./...
   go test ./...
   go build ./...

5. Keep pull requests focused and document any protocol version assumptions.

Architecture guardrails

The build enforces the core/adapter boundary at compile time via core/world/arch_test.go. If core/ imports an adapter, tests fail. This is intentional — it is the single most important invariant in the codebase. See Architecture.

Testing philosophy

GoCraft favours cross-edition parity tests: the same canonical interaction is driven through both Java and Bedrock inputs, and the resulting world/player/inventory/entity/sound state is compared. When adding a feature that touches both editions, add a differential test rather than trusting one adapter.

Data-driven changes

Block states, item IDs, entity types, biomes, and packet IDs live in versioned JSON under internal/gamedata/ and internal/protocoldata/ and are embedded with go:embed. Prefer updating data files over hardcoding maps.

Commit conventions

• Keep commits focused and reasonably small.
• Write clear messages describing the behaviour change, not just the files touched.

License

Contributions are made under the GNU General Public License v3.0 (GPL-3.0). Any modified or derived version must also be released under GPL-3.0.